Web page access track tracking method, device and equipment and storage medium

Abstract

The application discloses a Web page access track tracking method and device, equipment and storage medium, apply to access Web end's tracking tool, including: install and run the plug-in tool in the Web end, utilize the plug-in tool to collect the tracking data when the user accesses the Web page of the Web end; the tracking data is saved in the local storage of the Web end, and a data index is created for each tracking data; if the user feedbacks business failure information, the Web end extracts target tracking data according to the data index by triggering the user in the way of dyeing or the way of issuing active reporting entry; the target tracking data is reported to the link data query platform, and the link data query platform recovers the access track of the target Web page of the user when the business failure occurs based on the target tracking data. Avoid reporting a large number of irrelevant data to save communication resources, so that the page access track tracking is more targeted to improve the tracking efficiency.

Description

Technical Field

[0001] This invention relates to the field of link tracing technology, and in particular to a method, apparatus, device, and storage medium for tracing web page access paths. Background Technology

[0002] Data observability is crucial in business processing. Observability refers to how to infer and measure the internal state of a system from external output, describing the degree of understanding of what is happening in the system. It includes three main categories: metrics, logging, and tracing. Among related technologies, on the one hand, observability tracing technology is generally applied to the server side, with limited application in web pages, although existing web applications have an extremely urgent need for observability tracing technology. On the other hand, observability tracing applied to the server side only supports full reporting and sampled reporting. Full reporting does not meet the requirements of rationality and economy, while sampled reporting results in the discarding of data from links that did not meet the sampling criteria, which does not meet the common observability tracing scenarios in web pages.

[0003] Therefore, the aforementioned technical problems urgently need to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a method, apparatus, device, and storage medium for tracking web page access trajectories, which can avoid reporting large amounts of irrelevant data to save communication resources, while making page access trajectory tracking more targeted to improve tracking efficiency. The specific solution is as follows:

[0005] The first aspect of this application provides a method for tracking web page access patterns, applied to tracking tools accessing the web, including:

[0006] Install and run an instrumentation tool on the web platform to collect tracking data when users access web pages on the web platform.

[0007] The tracking data is saved in the local storage of the web client, and a data index is created for each piece of tracking data;

[0008] If a user reports a business failure, the web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry.

[0009] The target tracking data is reported to the link data query platform so that the link data query platform can recover the user's access trajectory to the target web page when a business failure occurs based on the target tracking data.

[0010] Optionally, saving the tracking data in local storage on the web client and creating a data index for each piece of tracking data includes:

[0011] A data table is created in the local storage on the web client, and the tracking data is saved in the data table according to the access date;

[0012] For each piece of tracking data stored in the data table, the network resource address of the accessed web page and the user ID at the time of access are used as the first data index.

[0013] Optionally, the web page access tracking method further includes:

[0014] The tracking data stored in the locally stored data table is monitored. When expired tracking data with an access date before a preset time is detected in the data table, the expired tracking data is deleted from the data table.

[0015] Optionally, after reporting the target tracking data to the link data query platform, the method further includes:

[0016] The data tags of the target tracking data that have been successfully reported and stored in the local storage data table are set to "reported" to prevent the tracking data with the "reported" data tag from being reported repeatedly.

[0017] Optionally, the web client is triggered to extract target tracking data from the local storage based on the data index by coloring the user, including:

[0018] A JS file carrying the coloring configuration is distributed; wherein the coloring configuration includes at least the coloring field of the first data index;

[0019] The web client triggers a user to revisit the JS file page to match the target tracking data in the coloring field of the coloring configuration in the locally stored data table, causing the web client to extract the target tracking data from the locally stored data table.

[0020] Optionally, the web client is triggered to extract target tracking data from the local storage based on the data index by issuing an active reporting entry, including:

[0021] Send out a reporting barcode containing the parameters of the first data index;

[0022] The web client triggers a user to access the reporting barcode by scanning it and then redirecting to an active reporting link page to match the target tracking data of the parameters in the reporting barcode in the locally stored data table, so that the web client can extract the target tracking data from the locally stored data table;

[0023] Accordingly, reporting the target tracking data to the link data query platform includes:

[0024] After a user on the web terminal triggers the automatic reporting component on the active reporting link page, the target tracking data is reported to the link data query platform.

[0025] Optionally, after reporting the target tracking data to the link data query platform, the method further includes:

[0026] Determine whether the report was successful. If so, display a screenshot notification on the active reporting link page to indicate successful upload, so that the user on the web can take a screenshot of the active reporting link page to indicate successful upload.

[0027] Optionally, the step of installing and running an instrumentation tool on the Web client to collect tracking data when a user accesses a Web page on the Web client includes:

[0028] Install and run the following on the Web client: a first instrumentation plugin for collecting server-side interface call data, a second instrumentation plugin for collecting Web client interface call data, a third instrumentation plugin for collecting user click behavior data, and a fourth instrumentation plugin for collecting JS error data.

[0029] The tracking data when a user accesses a web page on the web terminal is collected using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, respectively.

[0030] If the fourth instrumentation plugin does not collect JS error data, then the steps of saving the collected tracking data, creating an index, and reporting the target tracking data are executed.

[0031] Optionally, after collecting the tracking data when a user accesses a web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, the method further includes:

[0032] If the fourth instrumentation plugin collects JS error data, it saves the collected tracking data of the currently accessed web page with JS error, and uses the unique identifier of the call chain of the currently accessed web page with JS error as the second data index.

[0033] Based on the second data index, the tracking data of the currently accessed web page with JS errors is extracted from the local storage of the web client and reported to the link data query platform.

[0034] Optionally, if the fourth instrumentation plugin collects JS error data, it further includes:

[0035] The system reports the unique identifier of the call chain and the corresponding error stack of the currently accessed web page containing a JS error to the page error monitoring and alarm platform, so that the page error monitoring and alarm platform carries the unique identifier of the call chain in the error log; wherein, the user can jump to the link data query platform to query the tracking data corresponding to the unique identifier of the call chain by clicking on the unique identifier of the call chain carried in the error log.

[0036] Optionally, after collecting the tracking data when a user accesses a web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, the method further includes:

[0037] If the first instrumentation plugin collects server-side interface call data, it adds the unique identifier of the call chain of the currently accessed web page as a parameter to the server-side interface call request. This allows the server to generate backend tracing data based on the unique identifier of the call chain and report the corresponding backend tracing data along with the target tracing data. This enables the link data query platform to recover the user's access trajectory to the target web page in the event of a business failure based on the target tracing data and the corresponding backend tracing data. The backend tracing data reflects the call chain between the server and other terminals.

[0038] Optionally, the link data query platform recovers the user's access trajectory to the target web page during a business failure based on the target tracking data, including:

[0039] The link data query platform, built on a visualization open-source tool, will restore the user's access trajectory to the target web page when a business failure occurs based on the target tracking data, and visualize the restored access trajectory in the form of a data timeline.

[0040] A second aspect of this application provides a web page access trajectory tracking device, comprising:

[0041] The data acquisition module is used to install and run an instrumentation tool on the Web client to collect tracking data when a user visits a Web page on the Web client.

[0042] A local storage module is used to save the tracking data in the local storage of the Web client and create a data index for each piece of tracking data;

[0043] The first data retrieval module is used to trigger the web client to extract target tracking data from the local storage based on the data index if the user reports a business failure. This can be done by coloring the user or by sending an active reporting entry.

[0044] The data reporting module is used to report the target tracking data to the link data query platform, so that the link data query platform can recover the user's access trajectory to the target web page when a business failure occurs based on the target tracking data.

[0045] A third aspect of this application provides an electronic device including a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned web page access trajectory tracking method.

[0046] A fourth aspect of this application provides a computer-readable storage medium storing computer-executable instructions, which, when loaded and executed by a processor, implement the aforementioned web page access trajectory tracking method.

[0047] In this application, an instrumentation tool is installed and run on the web client to collect tracking data when a user accesses a web page. This tracking data is stored in the local storage of the web client, and a data index is created for each piece of tracking data. If a user reports a business failure, the web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user profile or issuing an active reporting entry. The target tracking data is then reported to a link data query platform, allowing the platform to recover the user's access trajectory to the target web page during a business failure. Therefore, this application integrates a tracking tool on the web client, which primarily tracks web page access trajectories. By storing the tracking data collected through instrumentation technology in the local storage of the web client instead of reporting the entire dataset, data can be reported only when a business failure occurs, and only the tracking data required for troubleshooting is reported, avoiding the reporting of large amounts of irrelevant data to save communication resources. This also makes page access trajectory tracking more targeted and improves tracking efficiency. Attached Figure Description

[0048] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0049] Figure 1 A schematic diagram of the hardware framework applicable to the Web page access trajectory tracking method provided in this application;

[0050] Figure 2 A flowchart of a web page access trajectory tracking method provided in this application;

[0051] Figure 3 A flowchart illustrating a specific method for tracking web page access patterns provided in this application;

[0052] Figure 4 This application provides a specific example diagram of IndexedDB local storage.

[0053] Figure 5 An example diagram illustrating a specific data retrieval method provided in this application;

[0054] Figure 6 This application provides a specific example diagram of a color configuration page;

[0055] Figure 7 A flowchart illustrating a specific method for tracking web page access patterns provided in this application;

[0056] Figure 8 Example diagram of another specific data retrieval method provided in this application;

[0057] Figure 9 An example diagram of a specific parameter setting page provided for this application;

[0058] Figure 10 An example image of a specific proactive reporting link page provided for this application;

[0059] Figure 11 This application provides a specific example screenshot of a webpage.

[0060] Figure 12 A flowchart illustrating a specific method for tracking web page access patterns provided in this application;

[0061] Figure 13 A flowchart illustrating a specific method for tracking web page access patterns provided in this application;

[0062] Figure 14 A schematic diagram illustrating a specific data concatenation query method provided in this application;

[0063] Figure 15 An example diagram of a specific data concatenation query interface provided in this application;

[0064] Figure 16 A flowchart illustrating a specific method for tracking web page access patterns provided in this application;

[0065] Figure 17 A schematic diagram illustrating another specific data concatenation query method provided in this application;

[0066] Figure 18 Another specific example diagram of a data concatenation query interface provided in this application;

[0067] Figure 19 A schematic diagram of a specific execution module provided in this application;

[0068] Figure 20 This is a schematic diagram of a web page access trajectory tracking device provided in this application. Detailed Implementation

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

[0070] Existing observability tracing technologies are mostly applied to the server side, with little involvement in the web side. Furthermore, server-side observability tracing only supports full reporting and sampled reporting. Full reporting fails to meet the requirements of rationality and economy, while sampled reporting results in the discarding of data from links that missed sampling, which does not meet the common observability tracing scenarios on the web side. To address these technical shortcomings, this application provides a web page access trajectory tracking scheme that avoids reporting large amounts of irrelevant data to save communication resources, while simultaneously making page access trajectory tracking more targeted to improve tracking efficiency.

[0071] To facilitate understanding, we will first introduce the hardware framework applicable to the web page access trajectory tracking method described in this application. See also... Figure 1 ,in, Figure 1 It shows a schematic diagram of the hardware framework applicable to the Web page access trajectory tracking method of this application.

[0072] Depend on Figure 1 It can be seen that the hardware framework may include an electronic device 10, wherein the electronic device 10 may include a processor 11, a memory 12, a communication interface 13, an input / output interface 14, and a communication bus 15. The processor 11, memory 12, communication interface 13, and input / output interface 14 all communicate with each other through the communication bus 15.

[0073] In this embodiment, the processor 11 can be a central processing unit (CPU), an application-specific integrated circuit, a digital signal processor, an off-the-shelf programmable gate array, or other programmable logic devices. The processor can call programs stored in the memory 12. Specifically, the processor can perform the operations executed on the computer device side in the following embodiments of the web page access trajectory tracking method.

[0074] The memory 12 stores one or more programs, which may include program code, including computer operation instructions. The program code can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as one or more of 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. In this embodiment, the memory stores at least a program for implementing the following functions:

[0075] Install and run an instrumentation tool on the web platform to collect tracking data when users access web pages on the web platform.

[0076] The tracking data is saved in the local storage of the web client, and a data index is created for each piece of tracking data;

[0077] If a user reports a business failure, the web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry.

[0078] The target tracking data is reported to the link data query platform so that the link data query platform can recover the user's access trajectory to the target web page when a business failure occurs based on the target tracking data.

[0079] In one possible implementation, the memory 12 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function (such as sound playback, image playback, etc.). The data storage area may store data created during the use of the electronic device, such as user data, tracking data, etc.

[0080] The communication interface 13 can be an interface for a communication module, such as the interface for a GSM module.

[0081] Input / output interface 14 provides an interface between processor 11 and other interface modules, such as keyboards, mice, and buttons. These buttons can be virtual or physical. Communication interface 13 is used for wired or wireless communication between electronic device 10 and other devices. Wireless communication includes Wi-Fi, Bluetooth, Near Field Communication (NFC), 2G, 3G, or 4G, or a combination thereof. Therefore, the corresponding communication component 105 may include a Wi-Fi component, a Bluetooth component, and an NFC component.

[0082] Electronic device 10 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to execute the web page access trajectory tracking method.

[0083] certainly, Figure 1 The structure of the electronic device 10 shown does not constitute a limitation on the computer device in the embodiments of this application. In practical applications, the electronic device may include more than Figure 1 More or fewer components as shown, or combinations of certain components.

[0084] in, Figure 1 The electronic device 10 can be a terminal (such as a mobile terminal like a mobile phone or tablet computer, or a fixed terminal like a PC), a server, or a smart electronic device.

[0085] Figure 2 A flowchart illustrating a web page access trajectory tracking method provided in this application embodiment. See also... Figure 2 As shown, this web page access tracking method includes:

[0086] S11: Install and run an instrumentation tool on the Web client to collect tracking data when a user visits a Web page on the Web client.

[0087] In this embodiment, the Tracer SDK is integrated into the web interface; that is, the Tracer SDK is loaded into the web page, and the Tracer SDK is the execution entity. The Tracer SDK is the toolkit used in this embodiment to implement the web page access trajectory tracking and reconstruction function. It conforms to the OpenTelemetry protocol and belongs to the observable specification. However, it should be noted that although it conforms to the relevant specifications and basic SDK provided by OpenTelemetry, it is completely different from the SDKs used on the server side in related technologies. The Tracer SDK in this embodiment is mainly used on the web interface.

[0088] In this embodiment, the web client that integrates the Tracer SDK can automatically install an instrumentation tool. The instrumentation tool starts running as soon as the user enters the web page. This tool is primarily used to collect data; specifically, it collects tracking data from the user's visits to the web page. This tracking data, or trace data, is collected and reported by the instrumentation tool based on the user's behavioral data during page access. Because the Tracer SDK is implemented using a plugin mechanism, the dimensions of the data to be automatically collected can be flexibly adjusted according to specific circumstances, such as the user's page dwell time and click coordinates.

[0089] S12: Save the tracking data in the local storage of the Web client, and create a data index for each piece of tracking data.

[0090] In this embodiment, after the instrumentation plugin on the web client collects the tracking data, considering that full reporting would report a large amount of normal data that is not used in the application scenario, consuming a lot of communication resources, an innovative local tracking data storage and retrieval scheme based on web client data storage is proposed. Specifically, after the instrumentation plugin on the web client collects the tracking data, it does not directly perform full reporting, but first saves the tracking data in the local storage on the web client, and at the same time creates a data index for each piece of tracking data.

[0091] In this embodiment, the Web client, also known as the browser client, uses IndexedDB for local storage. IndexedDB is a method of storing data on the browser side, enriching the client's query methods. Because it's local storage, it effectively reduces the impact of network traffic on page data. With IndexedDB, the browser can store more data, thus enriching the types of applications available on the browser side. This embodiment's local trace data storage and retrieval scheme based on browser IndexedDB primarily stores data collected from the Web page locally first. When needed, the required data is retrieved and reported using the retrieval method described below, eliminating the need for immediate full reporting and reducing unnecessary bandwidth and storage waste.

[0092] S13: If a user reports a business failure, the web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry.

[0093] In this embodiment, steps S11 and S12 are required for every web page access action by the user, and multiple tracking data entries are stored in the local storage of the web client. Data retrieval is awaited in different application scenarios, with web page troubleshooting being a crucial analysis scenario. In this application scenario, data retrieval is triggered by the user; that is, the user needs to report whether there is a business failure. If the user reports a business failure, the web client is triggered to extract the target tracking data from the local storage based on the data index, either by coloring the user profile or by issuing an active reporting entry.

[0094] In this embodiment, data retrieval during web page fault investigation primarily employs two methods: one is by coloring the user profile, and the other is by issuing an active reporting entry point. These two methods trigger the web client to extract target tracking data from its local storage based on the data index. It can be understood that the target tracking data is access data to a specific web page at the time the fault occurred, extracted from the web client's local storage.

[0095] S14: The target tracking data is reported to the link data query platform so that the link data query platform can recover the user's access trajectory to the target web page when a business failure occurs based on the target tracking data.

[0096] In this embodiment, after retrieving the required target tracking data from local storage, the target tracking data can be reported to the link data query platform. The link data query platform can then use the target tracking data to reconstruct the user's access trajectory to the target web page during a business failure. Based on the recovered access trajectory, web page failures can be accurately identified, thereby responding to user-reported business failures.

[0097] As can be seen, this embodiment of the application installs and runs an instrumentation tool on the Web client to collect tracking data when a user accesses a Web page on the Web client. The tracking data is saved in the local storage of the Web client, and a data index is created for each piece of tracking data. If a user reports a business failure, the Web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry. The target tracking data is then reported to the link data query platform, so that the link data query platform can recover the user's access trajectory to the target Web page when a business failure occurs based on the target tracking data. This embodiment of the application integrates a tracking tool on the Web client, which primarily tracks the Web page access trajectory. By saving the tracking data collected through instrumentation technology to the local storage of the Web client instead of reporting the entire dataset, data can be reported only when a business failure occurs, and only the tracking data required for troubleshooting the business failure needs to be reported, avoiding the reporting of a large amount of irrelevant data to save communication resources. This also makes page access trajectory tracking more targeted, improving tracking efficiency.

[0098] Figure 3 A flowchart illustrating a specific web page access tracking method provided in this application embodiment. See also... Figure 3 As shown, this web page access tracking method includes:

[0099] S21: Install and run an instrumentation tool on the Web client to collect tracking data when a user visits a Web page on the Web client.

[0100] In this embodiment, the specific process of step S21 can be referred to the corresponding content disclosed in the previous embodiments, and will not be repeated here.

[0101] S22: Create a data table in the local storage on the Web client, and save the tracking data in the data table according to the access date.

[0102] In this embodiment, the specific process of local storage is mainly described. First, a data table needs to be created in the local storage on the Web client. Then, the tracking data is saved in the data table according to the access date, for example, by creating a table for storage by day.

[0103] Furthermore, to avoid excessive consumption of users' browser storage space, expired data monitoring can be performed each time the Tracer SDK is activated. Specifically, the tracking data stored in the locally stored data table is monitored. When expired tracking data with an access date prior to a preset time is detected in the data table, the expired tracking data is deleted from the data table. For example, data stored more than 7 days ago is deleted each time the Tracer SDK is activated.

[0104] It should be noted that in scenarios requiring more granular analysis of page loading performance, the default sampling rate for trace data is 1%. Data that is sampled is reported directly; otherwise, it is stored in the browser's IndexedDB. Specifically... Figure 4 As shown.

[0105] S23: For each piece of tracking data stored in the data table, the network resource address of the accessed Web page and the user ID number at the time of access are used as the first data index.

[0106] In this embodiment, a data index needs to be created for each piece of tracking data stored in the data table. One method is to use the network resource address of the accessed web page and the user identifier at the time of access as the first data index. The term "first" is only used to indicate that it differs from another data index creation method and does not imply any other meaning. The network resource address is the URL (uniform resource locator), and the user identifier is the uin (User Identification Number).

[0107] S24: If the user reports a business failure, a JS file carrying the coloring configuration is sent; wherein the coloring configuration includes at least the coloring field of the first data index.

[0108] S25: Trigger the user on the web client to revisit the JS file page to match the target tracking data in the coloring configuration field of the coloring configuration in the locally stored data table, so that the web client extracts the target tracking data from the locally stored data table.

[0109] S26: Report the target tracking data to the link data query platform.

[0110] In this embodiment, when a user reports a service failure, data is retrieved primarily by coloring the user profile, specifically as follows: Figure 5 As shown. First, a JS file carrying the coloring configuration is distributed, wherein the coloring configuration includes at least the coloring field of the first data index. Figure 6 The image shows the coloring configuration page. The coloring fields are the first data index uin and url. In addition, since the table is created by day, time is also a coloring field in the coloring configuration.

[0111] After the JS file carrying the coloring configuration is distributed, the user on the web client is triggered to revisit the JS file page to find the target tracking data in the coloring field of the coloring configuration in the locally stored data table. This allows the web client to extract the target tracking data from the locally stored data table. For example, the final target tracking data might be the data in the data table with uin "532959769" and URL "https: / / iyqq.com / n2 / m / myservice / v3 / index.html". Finally, the target tracking data is reported to the link data query platform.

[0112] Figure 7 A flowchart illustrating a specific web page access tracking method provided in this application embodiment. See also... Figure 7 As shown, this web page access tracking method includes:

[0113] S31: Install and run an instrumentation tool on the Web client to collect tracking data when a user visits a Web page on the Web client.

[0114] S32: Create a data table in the local storage on the Web client, and save the tracking data in the data table according to the access date.

[0115] S33: For each piece of tracking data stored in the data table, the network resource address of the accessed Web page and the user ID number at the time of access are used as the first data index.

[0116] In this embodiment, the specific processes of steps S31 to S33 can be referred to the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0117] S34: If the user reports a service failure, a reporting barcode containing the parameters of the first data index is issued.

[0118] S35: The user on the web terminal is triggered to jump to the active reporting link page by scanning the reported barcode to find the target tracking data of the parameters in the reported barcode in the locally stored data table, so that the web terminal extracts the target tracking data from the locally stored data table.

[0119] S36: After a user on the Web terminal triggers the automatic reporting component on the active reporting link page, the target tracking data is reported to the link data query platform.

[0120] S37: Determine whether the report was successful. If so, display a screenshot notification instruction on the active reporting link page to indicate successful upload, so that the user on the web terminal can take a screenshot of the active reporting link page according to the screenshot notification instruction to indicate successful upload.

[0121] In this embodiment, when a user reports a service failure, the data is retrieved primarily by sending an active reporting portal, as detailed below. Figure 8 As shown. First, a reporting barcode containing the parameters of the first data index is sent. The aforementioned reporting barcode can be a QR code, barcode, etc., and this embodiment does not limit it. Figure 9 The parameters that need to be set are shown, including uin in the first data index and time. The final parameter is "time + uin", represented as tracer_user_report. For example, the final parameter can be tracer_user_report = 20220807u1022572613.

[0122] After a reporting barcode containing the parameters of the first data index is issued, the user on the web client is triggered to scan the reporting barcode and be redirected to an active reporting link page to match the target tracking data of the parameters in the reporting barcode in the locally stored data table. This allows the web client to extract the target tracking data from the locally stored data table. The active reporting link page is as follows: Figure 10 As shown. After a user on the web terminal triggers the automatic reporting component on the active reporting link page, the target tracking data is reported to the link data query platform. That is, when the user clicks... Figure 10 When the "Upload Log" button is pressed, the retrieved target tracking data is uploaded to the link data query platform.

[0123] Finally, to ensure successful upload, after the user clicks the "Upload" button, it is necessary to check whether the upload was successful. If so, a screenshot of the successful upload will be displayed on the active reporting link page to notify the user. Figure 11The message "Upload successful, please take a screenshot to notify" is the screenshot notification instruction. When a user on the web terminal sees this interface, they take a screenshot of the proactive reporting link page according to the screenshot notification instruction to indicate successful reporting.

[0124] Figure 12 A flowchart illustrating a specific web page access tracking method provided in this application embodiment. See also... Figure 12 As shown, this web page access tracking method includes:

[0125] S41: Install and run the following on the web: a first instrumentation plugin for collecting server-side interface call data, a second instrumentation plugin for collecting web-side interface call data, a third instrumentation plugin for collecting user click behavior data, and a fourth instrumentation plugin for collecting JS error data.

[0126] In this embodiment, the instrumentation tools installed and running on the web client include four types: a first instrumentation plugin for collecting server-side interface call data, a second instrumentation plugin for collecting web client interface call data, a third instrumentation plugin for collecting user click behavior data, and a fourth instrumentation plugin for collecting JS error data. Based on the plugin mechanism, each type of behavior data is encapsulated as an independent component, which takes effect after registration at the Tracer SDK entry point. By analyzing data from different dimensions, the efficiency of troubleshooting web page problems is enhanced.

[0127] In this embodiment, the instrumentation tool is mainly an Instrumentation plugin. Based on this, the first instrumentation plugin is represented as "instrumentation-xml-http-request", the second instrumentation plugin is represented as "instrumentation-native-jsbrigde", the third instrumentation plugin is represented as "instrumentation-user-interaction", and the fourth instrumentation plugin is represented as "instrumentation-js-error".

[0128] S42: Collect tracking data when a user accesses a web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, respectively.

[0129] In this embodiment, the first, second, third, and fourth instrumentation plugins are used to collect tracking data when a user accesses a web page on the web client. Specifically, after the web page integrates the Tracer SDK, it automatically monitors and collects various types of data, including: server-side interface request and response data, internal interface call trace data (collected by the first instrumentation plugin); client-side interface request and response data (collected by the second instrumentation plugin); user click behavior (collected by the third instrumentation plugin); and page JS error data (collected by the fourth instrumentation plugin).

[0130] S43: If the fourth instrumentation plugin does not collect JS error data, the tracking data is saved in the local storage of the web client, and a data index is created for each piece of tracking data.

[0131] S44: If a user reports a business failure, the web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry.

[0132] In this embodiment, if the fourth instrumentation plugin does not collect JS error data, meaning the web page accessed by the user does not exhibit JS errors, the process described in the previous embodiment is followed. The tracking data is saved in the local storage of the web client, and a data index is created for each piece of tracking data. When a user reports a business failure, data is passively reported. As mentioned earlier, the web client is triggered to extract the target tracking data from the local storage based on the data index by either coloring the user profile or issuing an active reporting entry.

[0133] S45: The target tracking data is reported to the link data query platform so that the link data query platform, built on a visualization open-source tool, can restore the user's access trajectory to the target web page when a business failure occurs based on the target tracking data, and visualize the restored access trajectory in the form of a data timeline.

[0134] In this embodiment, the link data query platform is built based on a visualization open-source tool. This means that in addition to querying and recovering the tracking data, it can also visualize the data. Specifically, after the target tracking data is finally reported to the link data query platform, the platform, built on the visualization open-source tool, will recover the user's access trajectory to the target web page during a business failure based on the target tracking data, and visualize the recovered access trajectory in the form of a data timeline.

[0135] It is understood that the link data query platform in this embodiment can be built based on open source frameworks such as Grafana and Jaeger, and this embodiment does not limit it.

[0136] Figure 13 A flowchart illustrating a specific web page access tracking method provided in this application embodiment. See also... Figure 13 As shown, this web page access tracking method includes:

[0137] S51: Install and run the following on the web: a first instrumentation plugin for collecting server-side interface call data, a second instrumentation plugin for collecting web-side interface call data, a third instrumentation plugin for collecting user click behavior data, and a fourth instrumentation plugin for collecting JS error data.

[0138] S52: Collect the tracking data when a user accesses a web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, respectively.

[0139] In this embodiment, the specific processes of steps S51 and S52 can be referred to the corresponding contents disclosed in the foregoing embodiments, and will not be repeated here.

[0140] S53: If the fourth instrumentation plugin collects JS error data, it saves the collected tracking data of the currently accessed Web page with JS errors and uses the unique identifier of the call chain of the currently accessed Web page with JS errors as the second data index.

[0141] S54: Extract the tracking data of the currently accessed web page with JS error from the local storage of the web client according to the second data index and report it to the link data query platform.

[0142] In this embodiment, if the fourth instrumentation plugin collects JS error data, it indicates that the currently accessed web page contains a JS error. At this time, the web client needs to actively report the trace data of the web page with the JS error. Before reporting, it still needs to be saved locally, and a data index also needs to be created. The difference is that in this case, the data index is the unique identifier of the call chain, `traceId`, that is, the unique identifier of the call chain of the currently accessed web page with the JS error is used as the second data index. Here, "second" is only to indicate that it differs from the other data index creation method and does not imply any other meaning.

[0143] It is understandable that each time a user enters a page, a unique access identifier, called a traceId, is generated, and each action generates a unique action identifier, called a spanId. All spanIds are linked to the traceId to form the user's access trajectory. In this embodiment, the data index for actively reporting the current trace data is the unique identifier of the call chain, traceId. Specifically, based on the second data index, the trace data of the currently accessed web page with a JS error is extracted from the local storage of the web client and reported to the link data query platform.

[0144] S55: Report the unique identifier of the call chain of the currently accessed web page with a JS error and the corresponding error stack to the page error monitoring and alarm platform, so that the page error monitoring and alarm platform carries the unique identifier of the call chain in the error log; wherein, the user jumps to the link data query platform by clicking the unique identifier of the call chain carried in the error log to query the tracking data corresponding to the unique identifier of the call chain.

[0145] In this embodiment, to enable the interconnection of trace data generated by other components used by the web page, the data from all parties is linked together by exposing or transmitting the traceId to achieve interconnected querying. The specific process for implementing data interconnection and querying between the page error monitoring and alarm platform and the link data query platform is as follows: The unique identifier of the call chain of the currently accessed web page with a JS error and the corresponding error stack are reported to the page error monitoring and alarm platform, so that the page error monitoring and alarm platform carries the unique identifier of the call chain in the error log; wherein, the user jumps to the link data query platform by clicking the unique identifier of the call chain carried in the error log to query the trace data corresponding to the unique identifier of the call chain. Figure 14 This is a flowchart illustrating the process described above. Figure 15 The left side of the image shows the error log displayed by the page error monitoring and alarm platform. Clicking on the traceId carried in the error log will redirect you to the link data query platform. Figure 15 (The interface shown on the right).

[0146] Figure 16 A flowchart illustrating a specific web page access tracking method provided in this application embodiment. See also... Figure 16 As shown, this web page access tracking method includes:

[0147] S61: Install and run the following on the web: a first instrumentation plugin for collecting server-side interface call data, a second instrumentation plugin for collecting web-side interface call data, a third instrumentation plugin for collecting user click behavior data, and a fourth instrumentation plugin for collecting JS error data.

[0148] S62: Collect the tracking data when the user accesses the web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, respectively.

[0149] In this embodiment, the specific processes of steps S61 and S62 can be referred to the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0150] S63: If the first instrumentation plugin collects server-side interface call data, it adds the unique identifier of the call chain of the currently accessed Web page as a parameter to the server-side interface call request. This allows the server to generate backend tracing data based on the unique identifier of the call chain and report the corresponding backend tracing data along with the target tracing data. This enables the link data query platform to recover the user's access trajectory to the target Web page in the event of a business failure based on the target tracing data and the corresponding backend tracing data. The backend tracing data reflects the call chain between the server and other terminals.

[0151] In this embodiment, to achieve interconnected querying of server-side trace data, traceId is exposed or transmitted. Specifically, if the first instrumentation plugin collects server-side interface call data, it adds the unique identifier of the call chain of the currently accessed web page as a parameter to the server-side interface call request. This allows the server to generate backend trace data based on the unique identifier of the call chain and report the corresponding backend trace data along with the target trace data. This enables the link data query platform to recover the user's access trajectory to the target web page when a business failure occurs, based on the target trace data and the corresponding backend trace data. The backend trace data reflects the call chain between the server and other terminals. The specific process is as follows... Figure 17 As shown, the query interface is as follows Figure 18 As shown

[0152] For easier understanding, please refer to Figure 19 (Execution Module) This section will introduce one application scenario of this solution. The following uses QQ Music Web client and the link data query platform server as application scenarios to illustrate the process of Web page access trajectory tracking.

[0153] Considering the large volume of trace data to be collected, which increases with the number of connected web pages, and that in page fault diagnosis scenarios, only trace data relevant to the occurrence of a fault is meaningful. OpenTelemetry only supports full reporting and sampled reporting; full reporting is neither reasonable nor economical, while sampled reporting may miss some scenarios that were not sampled. Therefore, considering reasonableness, economy, and accuracy, this embodiment innovatively implements a solution with local storage and data retrieval capabilities.

[0154] In this scenario, the Tracer SDK collection includes the QQ Music SDK for the web side. Of course, it can be expanded to include other business SDKs depending on the needs of the scenario. The trace data collected through instrumentation technology is batch exported from the web-side cache, serialized, and then imported into IndexedDB for storage.

[0155] When troubleshooting web page failures, we passively accept user-reported business faults. In this case, we can allow users to access the page via a specific QR code, or we can colorize the user ID. Based on the uin and url indexes, we can export trace data at the time of the fault from the IndexedDB and upload it to the link data query platform server. The trace data at the time of the fault is generally access data from a specific historical day. The data export format can be Zipkin, and the reporting interface is " / api / v2 / spans". Of course, this embodiment does not limit the data export format. In addition to supporting Zipkin, it also supports many other formats, which can be achieved by using different reporting adapters.

[0156] When a JS error occurs, the system proactively reports the current access data. In this case, trace data at the time of the JS error is exported from the indexedDB based on the traceid index and uploaded to the link data query platform server (a sampling rate of 10% can be set to improve data processing efficiency). The trace data at the time of the JS error is generally the data from a single access. Similarly, the data export format is Zipkin, and the reporting interface is " / api / v2 / spans".

[0157] Finally, the reported data can be displayed using open-source platforms such as Grafana or Jaeger.

[0158] See Figure 20 As shown in the figure, this application also discloses a web page access trajectory tracking device, including:

[0159] The data acquisition module 21 is used to install and run an instrumentation tool on the Web client to collect tracking data when a user accesses a Web page on the Web client using the instrumentation tool.

[0160] The local storage module 22 is used to save the tracking data in the local storage of the Web terminal and create a data index for each piece of tracking data;

[0161] The first data retrieval module 23 is used to trigger the Web client to extract target tracking data from the local storage based on the data index if the user reports business failure information, either by coloring the user or by sending an active reporting entry.

[0162] The data reporting module 24 is used to report the target tracking data to the link data query platform, so that the link data query platform can restore the user's access trajectory to the target web page when a business failure occurs based on the target tracking data.

[0163] As can be seen, this embodiment of the application installs and runs an instrumentation tool on the Web client to collect tracking data when a user accesses a Web page on the Web client. The tracking data is saved in the local storage of the Web client, and a data index is created for each piece of tracking data. If a user reports a business failure, the Web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry. The target tracking data is then reported to the link data query platform, so that the link data query platform can recover the user's access trajectory to the target Web page when a business failure occurs based on the target tracking data. This embodiment of the application integrates a tracking tool on the Web client, which primarily tracks the Web page access trajectory. By saving the tracking data collected through instrumentation technology to the local storage of the Web client instead of reporting the entire dataset, data can be reported only when a business failure occurs, and only the tracking data required for troubleshooting the business failure needs to be reported, avoiding the reporting of a large amount of irrelevant data to save communication resources. This also makes page access trajectory tracking more targeted, improving tracking efficiency.

[0164] In some specific embodiments, the local storage module 22 specifically includes:

[0165] A data table creation unit is used to create a data table in the local storage on the Web client;

[0166] The first storage unit is used to store the tracking data in a data table according to the access date;

[0167] The first index creation unit is used to use the network resource address of the accessed Web page and the user ID number at the time of access as the first data index for each piece of tracking data stored in the data table;

[0168] The detection and update unit is used to monitor the tracking data stored in the local storage data table. When it detects that there is expired tracking data in the data table with an access date before a preset time, it deletes the expired tracking data from the data table.

[0169] The tag setting unit is used to set the data tag of the target tracking data that has been successfully reported and stored in the local storage data table to "reported", so that the tracking data with the "reported" data tag will not be reported repeatedly.

[0170] In some specific embodiments, the first data retrieval module 23 specifically includes:

[0171] The first distribution unit is used to distribute a JS file carrying the coloring configuration; wherein the coloring configuration includes at least the coloring field of the first data index;

[0172] The first triggering unit is used to trigger the user on the web terminal to revisit the JS file page in order to hit the target tracking data in the coloring field of the coloring configuration in the locally stored data table, so that the web terminal extracts the target tracking data from the locally stored data table;

[0173] The second sending unit is used to send a reporting barcode containing parameters of the first data index;

[0174] The second triggering unit is used to trigger the user on the Web terminal to jump to the active reporting link page by scanning the reporting barcode to find the target tracking data of the parameters in the reporting barcode in the locally stored data table, so that the Web terminal extracts the target tracking data from the locally stored data table;

[0175] Correspondingly, the data reporting module 24 is specifically used to report the target tracking data to the link data query platform after the user on the Web terminal triggers the automatic reporting component on the active reporting link page.

[0176] In some specific embodiments, the web page access trajectory tracking device further includes:

[0177] The notification module is used to determine whether the report was successful. If so, a screenshot notification instruction for successful upload is displayed on the active reporting link page, so that the user on the web terminal can take a screenshot of the active reporting link page according to the screenshot notification instruction to notify that the report was successful.

[0178] In some specific embodiments, the data acquisition module 21 specifically includes:

[0179] The plugin setting unit is used to install and run a first instrumentation plugin for collecting server-side interface call data, a second instrumentation plugin for collecting web-side interface call data, a third instrumentation plugin for collecting user click behavior data, and a fourth instrumentation plugin for collecting JS error data on the Web client.

[0180] The data acquisition unit is used to collect the tracking data when a user accesses a web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, respectively.

[0181] In some specific embodiments, the web page access trajectory tracking device further includes a second data retrieval module and a data concatenation module, wherein the second data retrieval module specifically includes:

[0182] The second storage unit is used to save the tracking data of the currently accessed Web page with JS errors if the fourth instrumentation plugin collects JS error data.

[0183] The second index creation unit is used to use the unique identifier of the call chain of the currently accessed web page with a JS error as the second data index;

[0184] Correspondingly, the data reporting module 24 is specifically used to extract the tracking data of the currently accessed web page with JS error from the local storage of the web terminal according to the second data index and report it to the link data query platform;

[0185] The data concatenation module specifically includes:

[0186] The first data concatenation unit is used to report the unique identifier of the call chain of the currently accessed web page with JS errors and the corresponding error stack to the page error monitoring and alarm platform, so that the page error monitoring and alarm platform carries the unique identifier of the call chain in the error flow; wherein, the user jumps to the link data query platform by clicking the unique identifier of the call chain carried in the error flow to query the tracking data corresponding to the unique identifier of the call chain.

[0187] The second data concatenation unit is used to add the unique identifier of the call chain of the currently accessed Web page as a parameter to the server interface call request if the first instrumentation plugin collects server interface call data. This allows the server to generate backend tracing data based on the unique identifier of the call chain and report the corresponding backend tracing data along with the target tracing data. This enables the link data query platform to recover the user's access trajectory to the target Web page in the event of a business failure based on the target tracing data and the corresponding backend tracing data. The backend tracing data reflects the call chain between the server and other terminals.

[0188] On the other hand, this application also provides an electronic device that may include a processor and a memory. The relationship between the processor and the memory in this electronic device can be referenced... Figure 1 .

[0189] The processor of the electronic device is used to execute the program stored in the memory;

[0190] The memory of the electronic device is used to store a program, which is used at least for:

[0191] Install and run an instrumentation tool on the web platform to collect tracking data when users access web pages on the web platform.

[0192] The tracking data is saved in the local storage of the web client, and a data index is created for each piece of tracking data;

[0193] If a user reports a business failure, the web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry.

[0194] The target tracking data is reported to the link data query platform so that the link data query platform can recover the user's access trajectory to the target web page when a business failure occurs based on the target tracking data.

[0195] Of course, the electronic device may also include communication interfaces, input / output interfaces, etc., without any specific restrictions here.

[0196] Furthermore, this application also discloses a storage medium storing a computer program. When the computer program is loaded and executed by a processor, it implements the Web page access trajectory tracking method steps disclosed in any of the foregoing embodiments.

[0197] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0198] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0199] The Web page access trajectory tracking method, apparatus, device, and storage medium provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method of tracking a web page access trail, characterized by, Tracking tools applied to web-based access include: Install and run an instrumentation tool on the web platform to collect tracking data when users access web pages on the web platform. The tracking data is saved in the local storage of the web client, and a data index is created for each piece of tracking data; If a user reports a business failure, the web client is triggered to extract target tracking data from the local storage based on the data index by either coloring the user or issuing an active reporting entry. The target tracking data is reported to the link data query platform so that the link data query platform can recover the user's access trajectory to the target web page when a business failure occurs based on the target tracking data; The step of saving the tracking data in local storage on the web client and creating a data index for each piece of tracking data includes: A data table is created in the local storage on the web client, and the tracking data is saved in the data table according to the access date; For each piece of tracking data stored in the data table, the network resource address of the accessed web page and the user ID number at the time of access are used as the first data index; Specifically, triggering the web client to extract target tracking data from the local storage based on the data index by coloring the user includes: The first data index containing the network resource address and the user identifier is used as the coloring field to obtain a coloring configuration that includes at least the first data index. Send the JS file containing the coloring configuration; The web client triggers a user to revisit the JS file page to match the target tracking data in the coloring field of the coloring configuration in the locally stored data table, causing the web client to extract the target tracking data from the locally stored data table.

2. The Web page access trail tracking method of claim 1, wherein, Also includes: The tracking data stored in the locally stored data table is monitored. When expired tracking data with an access date before a preset time is detected in the data table, the expired tracking data is deleted from the data table.

3. The Web page access trail tracking method of claim 1, wherein, After reporting the target tracking data to the link data query platform, the process further includes: The data tags of the target tracking data that have been successfully reported and stored in the local storage data table are set to "reported" to prevent the tracking data with the "reported" data tag from being reported repeatedly.

4. The Web page access trail tracking method of claim 1, wherein, The web client is triggered to extract target tracking data from local storage based on the data index by issuing an active reporting entry point, including: Send out a reporting barcode containing the parameters of the first data index; The web client triggers a user to access the reporting barcode by scanning it and then redirecting to an active reporting link page to match the target tracking data of the parameters in the reporting barcode in the locally stored data table, so that the web client can extract the target tracking data from the locally stored data table; Accordingly, reporting the target tracking data to the link data query platform includes: After a user on the web terminal triggers the automatic reporting component on the active reporting link page, the target tracking data is reported to the link data query platform.

5. The Web page access trail tracking method of claim 4, wherein, After reporting the target tracking data to the link data query platform, the process further includes: Determine whether the report was successful. If so, display a screenshot notification on the active reporting link page to indicate successful upload, so that the user on the web can take a screenshot of the active reporting link page to indicate successful upload.

6. The Web page access trail tracking method of claim 1, wherein, The step of installing and running an instrumentation tool on the web platform to collect tracking data when users access web pages on the web platform includes: Install and run the following on the Web client: a first instrumentation plugin for collecting server-side interface call data, a second instrumentation plugin for collecting Web client interface call data, a third instrumentation plugin for collecting user click behavior data, and a fourth instrumentation plugin for collecting JS error data. The tracking data when a user accesses a web page on the web terminal is collected using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, respectively. If the fourth instrumentation plugin does not collect JS error data, then the steps of saving the collected tracking data, creating an index, and reporting the target tracking data are executed.

7. The Web page access trail tracking method of claim 6, wherein, After collecting the tracking data when a user accesses a web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, the method further includes: If the fourth instrumentation plugin collects JS error data, it saves the collected tracking data of the currently accessed web page with JS error, and uses the unique identifier of the call chain of the currently accessed web page with JS error as the second data index. Based on the second data index, the tracking data of the currently accessed web page with JS errors is extracted from the local storage of the web client and reported to the link data query platform.

8. The Web page access trail tracking method of claim 7, wherein, If the fourth instrumentation plugin collects JS error data, the following is also included: The system reports the unique identifier of the call chain and the corresponding error stack of the currently accessed web page containing a JS error to the page error monitoring and alarm platform, so that the page error monitoring and alarm platform carries the unique identifier of the call chain in the error log; wherein, the user can jump to the link data query platform to query the tracking data corresponding to the unique identifier of the call chain by clicking on the unique identifier of the call chain carried in the error log.

9. The Web page access trail tracking method of claim 6, wherein, After collecting the tracking data when a user accesses a web page on the web terminal using the first instrumentation plugin, the second instrumentation plugin, the third instrumentation plugin, and the fourth instrumentation plugin, the method further includes: If the first instrumentation plugin collects server-side interface call data, it adds the unique identifier of the call chain of the currently accessed web page as a parameter to the server-side interface call request. This allows the server to generate backend tracing data based on the unique identifier of the call chain and report the corresponding backend tracing data along with the target tracing data. This enables the link data query platform to recover the user's access trajectory to the target web page in the event of a business failure based on the target tracing data and the corresponding backend tracing data. The backend tracing data reflects the call chain between the server and other terminals.

10. The Web page access trail tracking method according to any one of claims 1 to 9, characterized by, The link data query platform recovers the user's access trajectory to the target web page during a business failure based on the target tracking data, including: The link data query platform, built on a visualization open-source tool, will restore the user's access trajectory to the target web page when a business failure occurs based on the target tracking data, and visualize the restored access trajectory in the form of a data timeline.

11. A web page access trajectory tracking apparatus characterized by comprising: The web page access trajectory tracking device is used to implement the web page access trajectory tracking method as described in any one of claims 1 to 10, and the web page access trajectory tracking device includes: The data acquisition module is used to install and run an instrumentation tool on the Web client to collect tracking data when a user visits a Web page on the Web client. A local storage module is used to save the tracking data in the local storage of the Web client and create a data index for each piece of tracking data; The first data retrieval module is used to trigger the web client to extract target tracking data from the local storage based on the data index if the user reports a business failure. This can be done by coloring the user or by sending an active reporting entry. The data reporting module is used to report the target tracking data to the link data query platform, so that the link data query platform can recover the user's access trajectory to the target web page when a business failure occurs based on the target tracking data.

12. An electronic device, comprising: The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the Web page access trajectory tracking method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, Used to store computer-executable instructions, which, when loaded and executed by a processor, implement the Web page access trajectory tracking method as described in any one of claims 1 to 10.

Images