Method, device and equipment for collecting buried point data based on routing and storage medium thereof
By rewriting the history management rules and determining the routes corresponding to the target actions, comprehensive data collection of user behavior is achieved, solving the problem of incomplete point-of-sale data in existing technologies and improving the integrity of data collection and analysis accuracy.
Patent Information
- Application Number
- CN202510730140.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-30
- Publication Date
- 2025-09-16
AI Technical Summary
In the existing technology, the automatic tracking method that relies on simple routing monitoring to determine page jumps collects incomplete tracking data and is unable to capture unconventional user behaviors that do not cause page jumps, resulting in low integrity of data collection.
By obtaining the target behavior data generated by multiple target actions of the user, rewriting the history management rules, generating historical records corresponding to the target actions, determining the routes corresponding to the historical records, and collecting buried data based on the routes, it is ensured that when the target action corresponding to any target behavior data occurs, the system can accurately record and collect data.
It improves the integrity of tracking data, provides more reliable user behavior analysis and data tracking support, fills the perception blind spots of traditional routing monitoring mechanisms, and ensures the comprehensiveness and accuracy of data.
Smart Images
Figure CN120658635A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a method, device, equipment and storage medium for collecting point-of-sale data based on routing. Background Art
[0002] Tracking is a technology used to collect user behavior data. In front-end development, tracking on application pages is a key means of collecting user behavior data and analyzing user paths. For example, in the field of internet finance, online financial products typically include functions such as loan applications, cash flow, account management, and investment and financial management. Collecting user behavior data from these functions through tracking technology is crucial for improving user experience, optimizing product features, and increasing product conversion rates.
[0003] In existing technologies, more comprehensive data collection is primarily achieved through automatic tracking. Automatic tracking, without developer intervention, automatically collects large amounts of data through software development kits. For example, in a single-page application (SPA), the automatic tracking system monitors route changes to detect page jumps and collects tracking data. However, relying solely on simple route monitoring to determine page jumps results in incomplete tracking data, resulting in low integrity. Summary of the Invention
[0004] The main purpose of this application is to provide a routing-based point-of-sale data collection method, device, equipment and storage medium, aiming to improve the integrity of the collected point-of-sale data.
[0005] In a first aspect, the present application provides a method for collecting data from a location based on routing, comprising:
[0006] Acquire multiple target behavior data generated by multiple target actions of the user based on preset applications;
[0007] rewriting the history record management rules of the preset application based on the plurality of target behavior data;
[0008] In response to triggering of the target action, generating a historical record corresponding to the target action by using the rewritten historical record management rule;
[0009] Determine a first route corresponding to the historical record, and determine a burial point corresponding to the first route;
[0010] Based on the embedding point corresponding to the first route, data of the target page of the preset application is collected.
[0011] In a second aspect, the present application further provides a routing-based buried point data collection device, the routing-based buried point data collection device comprising:
[0012] A data acquisition module is used to acquire multiple target behavior data generated by multiple target actions of the user based on preset applications;
[0013] A rule rewriting module, configured to rewrite the history record management rules of the preset application based on the plurality of target behavior data;
[0014] a record generation module, configured to generate a historical record corresponding to the target action by using the rewritten historical record management rule in response to the triggering of the target action;
[0015] A route determination module, configured to determine a first route corresponding to the historical record;
[0016] The data collection module is used to collect data of the target page of the preset application based on the embedding point corresponding to the first route.
[0017] In a third aspect, the present application also provides a computer device, which includes a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, the steps of the routing-based point data collection method as described above are implemented.
[0018] In a fourth aspect, the present application also provides a computer-readable storage medium, on which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the routing-based point data collection method as described above are implemented.
[0019] The present application provides a method, device, equipment and storage medium for collecting point data based on routing. The present application obtains multiple target behavior data generated by multiple target actions of a user based on a preset application; based on the multiple target behavior data, rewrites the history record management rules of the preset application; in response to the triggering of the target action, generates a historical record corresponding to the target action using the rewritten history record management rules; determines the first route corresponding to the historical record; and collects data of the target page of the preset application based on the point corresponding to the first route. The historical record management rules are rewritten by the rewriting logic corresponding to the multiple target behavior data to ensure that when the target action corresponding to any target behavior data occurs, the system can generate the corresponding historical record using the rewritten history record management rules to ensure that the target action is accurately recorded, so that the point corresponding to the target action can be determined based on the historical record, and then the data of the target page is collected in a timely and comprehensive manner using the point. This not only greatly improves the integrity of the collected point data, but also provides more reliable data support for subsequent user behavior analysis, data tracking, etc. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0021] Figure 1 A schematic diagram of the steps of a routing-based point data collection method provided in an embodiment of the present application;
[0022] Figure 2 for Figure 1 A schematic diagram of the sub-step flow of the routing-based buried point data collection method;
[0023] Figure 3 A schematic block diagram of a routing-based point-of-sale data acquisition device provided in an embodiment of the present application;
[0024] Figure 4 for Figure 3 A schematic block diagram of a submodule of a routing-based buried point data acquisition device;
[0025] Figure 5 A schematic block diagram of the structure of a computer device provided in an embodiment of the present application.
[0026] The realization of the objectives, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION
[0027] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.
[0028] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, combined, or partially merged, so the actual execution order may vary depending on the actual situation.
[0029] The embodiments of the present application provide a method, apparatus, device, and storage medium for collecting data points based on routing. The method can be applied to a terminal device or server, where the terminal device can be an electronic device such as a mobile phone, tablet computer, laptop computer, desktop computer, personal digital assistant, or wearable device. The server can be a single server or a server cluster consisting of multiple servers.
[0030] The following describes some embodiments of the present application in detail with reference to the accompanying drawings. In the absence of conflict, the following embodiments and features therein may be combined with each other.
[0031] Please refer to Figure 1 , Figure 1 A schematic diagram of the steps of a routing-based point data collection method provided in an embodiment of the present application.
[0032] like Figure 1 As shown, the routing-based buried point data collection method includes steps S101 to S105.
[0033] Step S101: Acquire multiple target behavior data generated by multiple target actions of a user based on a preset application.
[0034] Pre-defined applications are pre-defined applications or software tools for users, such as e-commerce platforms and social media applications. Pre-defined applications can have multiple functional modules and interactive components, such as keyword search modules, product browsing modules, and order payment modules. Multiple interactive components include search boxes, form submission buttons, confirm buttons, delete icons, navigation menus, and comment boxes.
[0035] Target actions are specific, interactive, or operational behaviors that users perform when using a pre-defined application. Examples of target actions include swiping, tapping, double-clicking, and long-pressing on the user interface. Target action data is the recorded data of user behaviors related to the target action, including the timing, location, and parameters of the target action trigger.
[0036] It should be noted that users can generate target behavior data based on the target action of a preset application. For example, if the target action is a user clicking the "Submit" button after filling out a form, the corresponding target behavior data includes the time the Submit button was clicked, the URL of the page where the form is located, the form field data (such as name, email address), and the user ID.
[0037] It should be noted that during user interaction with a pre-set application, user actions can be roughly categorized as regular actions and irregular actions based on the different page states of the pre-set application. Regular actions can cause routing changes, and the system collects tracking data after monitoring these routing changes. However, irregular actions cannot cause routing changes, and the system cannot collect tracking data for these irregular behaviors by monitoring routing changes.
[0038] Specifically, target actions can include unconventional behaviors that fail to trigger page redirects or page refreshes within the default application. Unconventional actions are relatively rare but real user interactions within an application, such as selecting a drop-down menu, changing filter status, or scrolling within a page. While these actions do not trigger page redirects or view refreshes, and are therefore difficult to detect through traditional route change monitoring mechanisms, they are still valid user behaviors and can reflect the user's true intent.
[0039] Therefore, although these unconventional actions will not trigger route changes, they often carry valuable interaction data. By using these unconventional actions as target actions and the behavioral data corresponding to these unconventional actions as target behavioral data, we can fill the gap in existing technologies that cannot capture such unconventional actions through traditional route monitoring mechanisms, ensure the integrity of the subsequent collected tracking data, and thus help achieve a comprehensive perception of user behavior, thereby improving the accuracy and breadth of data analysis and user experience optimization.
[0040] In one embodiment, if Figure 2 As shown, step S101 includes: sub-steps S1011 to S1013.
[0041] Sub-step S1011: obtaining a plurality of actual behavior data generated by a user performing a plurality of preset actions of a preset application, and obtaining a plurality of calibrated behavior data of the preset actions.
[0042] Preset actions are user interactions within an app. It's understood that multiple preset actions should cover, as far as possible, all possible interactions a user might perform in different contexts when using the app. Actual behavior data refers to the behavioral data generated by a user's actions within a preset app, captured by the system through monitoring route changes. This behavioral data corresponds to a subset of the preset actions. Calibrated behavior data, on the other hand, refers to relatively complete behavioral data captured by the system under ideal circumstances through a variety of means, not limited to monitoring route changes. This behavioral data corresponds to all preset actions.
[0043] Sub-step S1012: comparing the plurality of actual behavior data with the plurality of calibration behavior data, and determining a plurality of target actions from a plurality of preset actions based on the comparison result.
[0044] Specifically, if one of the multiple preset actions is recorded in the calibration behavior data but is missing in the actual behavior data, it means that the action did not cause a route change, and the system failed to monitor the occurrence of the action. At this time, the action is determined to be the target action. For example, in an e-commerce application, suppose one of the preset actions is "the user clicks the filter to filter products." In the calibration behavior data, the system simulates the action and successfully records the data of the filter being clicked and the filter conditions changing (such as selecting a price range, brand, or rating, etc.). However, in the actual user behavior data, the system failed to capture this operation. Even if the user performed a filtering operation, the filtering behavior did not trigger a page refresh or route change, so the system failed to effectively monitor this behavior.
[0045] It is understandable that through the comparative analysis process, the system can effectively screen out those unconventional behaviors that have not been monitored and cannot cause page jumps, namely "target actions".
[0046] Sub-step S1013: using the calibration behavior data corresponding to each target action as target behavior data.
[0047] The calibrated behavioral data for target actions can help identify system shortcomings in user behavior perception. Specifically, traditional monitoring methods rely primarily on page jumps to capture user actions, but this approach has a blind spot, namely, it lacks the ability to perceive user actions that do not cause page jumps. Therefore, by determining the target action and its calibrated action, it can provide a key basis for subsequent system optimization, and can supplement and improve these unconventional behaviors, thereby resolving the problem of the perception blind spot of user actions without jump behavior that exists in monitoring methods that rely on page jumps.
[0048] It should be noted that in order to further ensure the privacy and security of the above-mentioned target behavior data and other related information, the above-mentioned target behavior data and other related information can also be stored in a node of a blockchain. The technical solution of this application can also be applied to adding other data files stored on the blockchain. The blockchain referred to in this application is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
[0049] Step S102: rewrite the history record management rules of the preset application based on the plurality of target behavior data.
[0050] The history record management rules may be rules and methods for defining and controlling how to manage browser history records in a preset application. For example, the history record management rules may include, but are not limited to, creating, updating, deleting, and synchronizing entries in the browser history records.
[0051] Specifically, in a single-page application (SPA), before its history management rules are rewritten, each user interaction behavior (such as switching views, loading new content, etc.) may not cause a page jump or refresh, resulting in some user interaction behaviors not being recorded, and the SPA's browser history will not change accordingly, which is not conducive to the subsequent accurate tracking and data analysis of user interaction behaviors.
[0052] Therefore, to ensure that the application can more accurately capture all user interactions, the history management rules need to be rewritten. For example, by rewriting pushState, which can add new history entries to the history, we can ensure that even without a page refresh, each user interaction will update the browser history, and the system can track every user action. For another example, rewriting replaceState, which can modify the current history entry in the history, can avoid unnecessary entry accumulation and ensure that updates to the page state are reflected in the history.
[0053] In one embodiment, the historical record management rules of the preset application are rewritten based on multiple target behavior data, including: obtaining the behavior attributes corresponding to each target behavior data; generating the rewriting logic corresponding to each target behavior data based on the behavior attributes corresponding to each target behavior data, and rewriting the historical record management rules of the preset application based on the multiple rewriting logics.
[0054] The behavior attributes corresponding to each target behavior data can be obtained through a mapping relationship table, which records the correspondence between multiple behavior data and multiple behavior attributes. The behavior attributes are used to describe the specific information of the target behavior corresponding to each target behavior data and are used to determine the behavior nature of each target behavior, such as interactive operation, view switching and content loading, pop-up window closing, etc., so as to further determine the rewriting logic corresponding to each target behavior data.
[0055] Among them, the behavior attribute is used to guide the subsequent rewriting of the historical record management rules corresponding to each target behavior data. For example, when the target behavior corresponding to a certain target behavior data is "switch from view A to view B", the behavior attribute of the target behavior is "view switch", and since the view switch requires the generation of a new historical record entry, the rewriting logic generated corresponding to the target behavior data can guide the subsequent rewriting of the modules (such as pushState) in the historical record management rules that can generate new historical record entries, thereby ensuring that when the target behavior data occurs, the rewritten historical record management rules can generate the corresponding historical record entry.
[0056] Therefore, by rewriting the history record management rules based on the rewriting logic corresponding to each target behavior data, we can ensure that when the target action corresponding to any target behavior data occurs, the system can use the rewritten history record management rules to generate the corresponding history record entry. This not only ensures that the target action is accurately reflected in the history record, but also provides more reliable data support for subsequent user behavior analysis and data tracking.
[0057] In another embodiment, rewriting the history record management rules of the preset application based on multiple target behavior data further includes: redefining the attributes of the history record management rules of the preset application based on multiple preset attribute characteristics.
[0058] Property characteristics can include configurability and writability, for example, adding configurable:true and writable:true configurations when overriding. Property characteristics can also include extensibility and enumerability, etc.
[0059] It should be noted that by updating the properties of the historical record management rules, the rewritten historical record management rules have attribute characteristics such as configurability and writability, ensuring that when conflicts arise between rewriting logics, the default historical record management rules need to be restored, or the system requirements change, developers can flexibly adjust the rewritten historical record management rules to ensure the security and stability of the system.
[0060] Step S103 : In response to the triggering of the target action, generate a history record corresponding to the target action by using the rewritten history record management rule.
[0061] For example, assume that one of the target actions of an application is "View Details". When the user clicks the "View Details" button on the application page, the system responds to the triggering of the target action "View Details" and calls pushState to generate its corresponding history record.
[0062] In one embodiment, in response to the triggering of a target action, a corresponding historical record is generated using the rewritten historical record management rules, including: in response to the triggering of the target action, obtaining the routing parameters associated with the triggering of the target action; merging multiple routing parameters, and generating historical records based on the merged routing parameters using the rewritten historical record management rules.
[0063] Among them, the routing parameters associated with the triggering of the target action can be the query parameters (query parameters) involved in the target action. For example, in a medical health APP, the user is browsing the medical product list page. Based on their own needs, the user selects multiple filtering conditions, such as device type (blood pressure monitor, blood glucose meter, etc.), price range and brand, etc. The system merges the multiple routing parameters corresponding to these filtering conditions, and updates the routing parameters corresponding to the user's "browse medical product list page" action accordingly to ensure that the user's filtering operation is fully recorded. Based on the updated routing parameters, the system uses pushState to generate new history entries to ensure that the user's actions can be correctly recorded in the browser's history, while also making it easier for users to backtrack.
[0064] Step S104: Determine the first route corresponding to the historical record.
[0065] A route refers to the path a user takes from one page or view to another. Specifically, every time a user performs an action on an application, the browser automatically records the action's history. This history can include information such as the route to the current page, the time of the action, and the status of the request (e.g., the history of forward and back actions). Therefore, based on the history, it's possible to determine which page or view the user is currently visiting, and thus, the first route associated with the user's current action.
[0066] Step S105: Based on the embedding point corresponding to the first route, data of the target page of the preset application is collected.
[0067] Among them, tracking points can be pre-set. Specifically, multiple tracking points are respectively bound to views or components corresponding to multiple different first routes. For example, the tracking point code is directly embedded in a specific location of the application (such as a page, button or module, etc.). When the user performs a specific operation at these locations, the corresponding tracking point logic will be triggered and relevant data (such as event time, user ID, operation content, etc.) can be collected. Tracking points can also be based on the path of the current first route, using a configured tracking point module, searching the tracking point configuration corresponding to the current first path from the tracking point module and performing the corresponding tracking point collection operation.
[0068] It should be noted that after determining the tracking point corresponding to the first route, the data of the target page can be automatically collected through the tracking point without relying on user input or other manual intervention, ensuring that the tracking point data collection process is more accurate and reducing the risk of data omissions.
[0069] In one embodiment, before collecting data of a target page of a preset application based on the tracking point corresponding to the first route, it also includes: triggering a route change event based on the first route; and determining a tracking point that matches the first route from a preset tracking point module in response to the route change event.
[0070] It is understandable that the triggering of the route change event is based on the change of the first route, and the change of the first route depends on the generation of a new historical record. Among them, the change of the historical record can be monitored and responded to by calling events (such as window.onpopstate) or front-end route management tools (such as React Router, Vue Router), etc. For example, a user searches for the keyword "blood pressure monitor" on the product list page. This search action generates a historical record. The system monitors the generation of the historical record through Vue Router, and determines the route change by determining the first route corresponding to the historical record, thereby triggering the route change event.
[0071] The preset tracking module has multiple tracking points with different rules. When a route change event is triggered, one or more tracking rules are loaded from the tracking module based on the tracking configuration corresponding to the target route corresponding to the historical records. This ensures that the collected tracking data (such as page dwell time, operation path, etc.) matches the user behavior corresponding to the target route, thereby improving the integrity of the tracking data.
[0072] As you can see, when adding a new page or modifying tracking rules for an existing page, you only need to configure or adjust them in the tracking module without having to modify other tracking points, making the system more scalable. Furthermore, managing all tracking points through a separate module (i.e., the tracking module) makes it easier to modify, maintain, and upgrade tracking rules.
[0073] In one embodiment, the triggering of the route change event and the collection of the tracking data are performed asynchronously to ensure that the tracking logic corresponding to the collection of the tracking data is triggered after the route switching in the route change event is completed, thereby effectively avoiding the premature triggering or backlog of the route change event and improving the accuracy of subsequent tracking data collection.
[0074] In one embodiment, the routing-based buried point data collection method further includes: in response to receiving a data reporting task, obtaining multiple unreported buried point data; merging the multiple unreported buried point data and uploading them to a data server for storage.
[0075] Data reporting tasks can be configured based on actual conditions. For example, a reporting task can be automatically triggered when a preset time interval (e.g., every 5 minutes) is reached; another example is when the amount of collected data reaches a preset data quantity threshold (e.g., 10 data items); another example is when both the preset time interval and the preset data quantity threshold are reached, and so on. The delayed triggering mechanism of data reporting tasks can avoid frequent network requests and improve the upload efficiency of buried data.
[0076] In another embodiment, each buried point data has its corresponding identifier. Before merging the multiple buried point data that have not been reported, the process further includes: comparing the multiple identifiers corresponding to the multiple buried point data that have not been reported with the multiple cache identifiers to determine whether there is target buried point data with the same identifier as any of the cache identifiers; if so, removing the target buried point data from the multiple buried point data to be reported.
[0077] The identifier of the buried data can be an identifier that can reflect the uniqueness of the buried data, such as the buried event ID, event type, and timestamp. The cache identifier is the identifier of the buried data that has been uploaded to the data server. The cache identifier can be stored using a cache (such as a Set or Map). When executing a data upload task, the cache identifier stored in the cache can be directly retrieved from the cache, and after the new buried data is uploaded to the data server, the data in the cache can be updated accordingly.
[0078] It should be noted that by adopting mechanisms such as delayed triggering and data deduplication for data upload tasks, it is possible to ensure efficient reporting of buried data while also ensuring the uniqueness and integrity of the buried data.
[0079] The routing-based tracking data collection method provided in the above embodiment obtains multiple target behavior data generated by the user based on multiple target actions of a preset application; rewrites the historical record management rules of the preset application based on the multiple target behavior data; generates a historical record corresponding to the target action using the rewritten historical record management rules in response to the triggering of the target action; determines the first route corresponding to the historical record; and collects data of the target page of the preset application based on the tracking points corresponding to the first route. The historical record management rules are rewritten by the rewriting logic corresponding to the multiple target behavior data to ensure that when the target action corresponding to any target behavior data occurs, the system can generate the corresponding historical record using the rewritten historical record management rules to ensure that the target action is accurately recorded, thereby being able to determine the tracking points corresponding to the target action based on the historical records, and then using the tracking points to collect the data of the target page in a timely and comprehensive manner, which not only greatly improves the integrity of the collected tracking point data, but also provides more reliable data support for subsequent user behavior analysis, data tracking, etc.
[0080] Please refer to Figure 3 , Figure 3 A schematic block diagram of a routing-based point-of-sale data acquisition device provided in an embodiment of the present application.
[0081] like Figure 3 As shown, the routing-based buried point data collection device 200 includes:
[0082] The data acquisition module 201 is used to acquire a plurality of target behavior data generated by a user based on a plurality of target actions of a preset application;
[0083] A rule rewriting module 202 is used to rewrite the history management rules of the preset application based on multiple target behavior data;
[0084] A record generation module 203 is configured to generate a historical record corresponding to the target action by using the rewritten historical record management rules in response to the triggering of the target action;
[0085] A route determination module 204, configured to determine a first route corresponding to the historical record;
[0086] The data collection module 205 is used to collect data of the target page of the preset application based on the embedding point corresponding to the first route.
[0087] In one embodiment, the routing-based buried data collection device 200 further includes:
[0088] The attribute update module (not shown in the figure) is used to redefine the attributes of the history record management rules of the preset application based on multiple preset attribute characteristics; wherein the attribute characteristics at least include configurability and writability.
[0089] In one embodiment, the routing-based buried data collection device 200 further includes:
[0090] The data reporting module (not shown in the figure) is used to obtain multiple unreported burial point data in response to receiving a data reporting task; merge the multiple unreported burial point data and upload them to the data server for storage.
[0091] In one embodiment, Figure 4 As shown, the data acquisition module 201 includes:
[0092] The data collection submodule 2011 is used to obtain a plurality of actual behavior data generated by a user performing a plurality of preset actions on a preset application, and to obtain a plurality of calibrated behavior data of the preset actions.
[0093] The data comparison submodule 2012 is used to compare the multiple actual behavior data with the multiple calibration behavior data, and determine multiple target actions from multiple preset actions based on the comparison results.
[0094] The data determination submodule 2013 is configured to use the calibration behavior data corresponding to each target action as target behavior data.
[0095] In one embodiment, the rule rewriting module 202 is further configured to:
[0096] Obtaining the behavior attributes corresponding to each target behavior data;
[0097] Based on the behavior attributes corresponding to each target behavior data, generate the rewriting logic corresponding to each target behavior data;
[0098] Rewrite the history management rules of the preset application based on multiple rewriting logics.
[0099] In one embodiment, the record generation module 203 is further configured to:
[0100] In response to triggering of a target action, obtaining routing parameters associated with the triggering of the target action;
[0101] Multiple routing parameters are merged, and based on the merged routing parameters, a history record is generated by using the rewritten history record management rule.
[0102] In one embodiment, the data collection module 205 is further configured to:
[0103] Based on the first route, trigger a route change event;
[0104] In response to the route change event, a tracking point that matches the first route is determined from a preset tracking point module.
[0105] It should be noted that, those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described devices and modules and units can refer to the corresponding processes in the aforementioned routing-based point data collection method embodiment, and will not be repeated here.
[0106] The apparatus provided in the above embodiment can be implemented in the form of a computer program. The computer program can be used in Figure 5 Runs on the computer equipment shown.
[0107] See also Figure 5 , Figure 5 A schematic block diagram of the structure of a computer device provided in an embodiment of the present application.
[0108] like Figure 5 As shown, the computer device includes a processor, a memory and a network interface connected through a system bus, wherein the memory may include a storage medium and an internal memory, and the storage medium may be non-volatile or volatile.
[0109] The storage medium can store an operating system and a computer program. The computer program includes program instructions, which, when executed, can cause the processor to execute any one of the routing-based point-of-sale data collection methods.
[0110] The processor is used to provide computing and control capabilities and support the operation of the entire computer equipment.
[0111] The internal memory provides an environment for the operation of the computer program in the storage medium. When the computer program is executed by the processor, the processor can execute any routing-based point data collection method.
[0112] The network interface is used for network communication, such as sending assigned tasks, etc. Those skilled in the art will understand that Figure 5 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.
[0113] It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.
[0114] In one embodiment, the processor is configured to execute a computer program stored in the memory to implement the following steps:
[0115] Acquire multiple target behavior data generated by multiple target actions of the user based on preset applications;
[0116] Rewrite the history management rules of preset applications based on multiple target behavior data;
[0117] In response to the triggering of the target action, a historical record corresponding to the target action is generated using the rewritten historical record management rules;
[0118] Determine the first route corresponding to the historical record;
[0119] Based on the embedding point corresponding to the first route, data of the target page of the preset application is collected.
[0120] In one embodiment, the processor is further configured to implement:
[0121] Based on a plurality of preset attribute characteristics, the attributes of the history record management rule of the preset application are redefined; wherein the attribute characteristics at least include configurability and writability.
[0122] In one embodiment, the processor is further configured to implement:
[0123] In response to receiving the data reporting task, a plurality of unreported burial point data are obtained; the plurality of unreported burial point data are merged and uploaded to the data server for storage.
[0124] In one embodiment, when rewriting the history record management rules of a preset application based on multiple target behavior data, the processor is configured to implement:
[0125] Acquire multiple actual behavior data generated by multiple preset actions of the user on the preset application, and acquire calibrated behavior data of the multiple preset actions;
[0126] Comparing the plurality of actual behavior data with the plurality of calibration behavior data, and determining a plurality of target actions from a plurality of preset actions based on the comparison results;
[0127] The calibrated behavior data corresponding to each target action is used as the target behavior data.
[0128] In one embodiment, when rewriting the history record management rules of a preset application based on multiple target behavior data, the processor is configured to implement:
[0129] Obtaining the behavior attributes corresponding to each target behavior data;
[0130] Based on the behavior attributes corresponding to each target behavior data, generate the rewriting logic corresponding to each target behavior data;
[0131] Rewrite the history management rules of the preset application based on multiple rewriting logics.
[0132] In one embodiment, when the processor generates a historical record corresponding to the target action by using the rewritten historical record management rule in response to triggering the target action, the processor is configured to implement:
[0133] In response to triggering of a target action, obtaining routing parameters associated with the triggering of the target action;
[0134] Multiple routing parameters are merged, and based on the merged routing parameters, a history record is generated by using the rewritten history record management rule.
[0135] In one embodiment, before collecting data of a target page of a preset application based on the tracking point corresponding to the first route, the processor is further configured to:
[0136] Based on the first route, trigger a route change event;
[0137] In response to the route change event, a tracking point that matches the first route is determined from a preset tracking point module.
[0138] It should be noted that technical personnel in the relevant field can clearly understand that for the convenience and conciseness of description, the specific working process of the computer equipment described above can refer to the corresponding process in the aforementioned routing-based point data collection method embodiment, and will not be repeated here.
[0139] The present application can be used in many general or special computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and the like. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. The present application can also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media, including storage devices.
[0140] An embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored. The computer program includes program instructions. The method implemented when the program instructions are executed can refer to the various embodiments of the routing-based point data collection method of the present application.
[0141] The computer-readable storage medium may be an internal storage unit of the computer device described in the aforementioned embodiment, such as a hard disk or memory of the computer device. The computer-readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a SmartMedia Card (SMC), a Secure Digital (SD) card, a flash memory card, etc., equipped on the computer device.
[0142] Furthermore, the computer-usable storage medium may mainly include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function, etc.; the data storage area may store data created based on the use of blockchain nodes, etc. The blockchain referred to in this application is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains information about a batch of network transactions, which is used to verify the validity of its information (anti-counterfeiting) and generate the next block. The blockchain may include the blockchain underlying platform, the platform product service layer, and the application service layer.
[0143] It should be understood that the terms used in this specification are only for the purpose of describing specific embodiments and are not intended to limit the present application. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms unless the context clearly indicates otherwise.
[0144] It should also be understood that the term "and / or" used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, including these combinations. It should be noted that, in this article, the terms "include", "comprise" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system that includes a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also includes elements that are inherent to such process, method, article or system. In the absence of further restrictions, an element defined by the sentence "including a..." does not exclude the presence of other identical elements in the process, method, article or system that includes the element.
[0145] The serial numbers of the embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments. The above description is only a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.
Claims
1. A method for collecting buried data based on routing, characterized in that: include: Acquire multiple target behavior data generated by multiple target actions of the user based on preset applications; rewriting the history record management rules of the preset application based on the plurality of target behavior data; In response to triggering of the target action, generating a historical record corresponding to the target action by using the rewritten historical record management rule; Determine a first route corresponding to the historical record; Based on the embedding point corresponding to the first route, data of the target page of the preset application is collected.
2. The method for collecting data based on routing according to claim 1, characterized in that: The rewriting of the history record management rule of the preset application based on the plurality of target behavior data includes: Obtaining behavior attributes corresponding to each target behavior data; generating rewriting logic corresponding to each target behavior data based on the behavior attribute corresponding to each target behavior data; Based on the multiple rewriting logics, the history record management rules of the preset application are rewritten.
3. The method for collecting data based on routing according to claim 2, characterized in that: The method further comprises: Based on a plurality of preset attribute characteristics, the attributes of the history record management rule of the preset application are redefined; wherein the attribute characteristics at least include configurability and writability.
4. The method for collecting data based on routing according to claim 1, wherein: Before collecting data of the target page of the preset application based on the tracking point corresponding to the first route, the method further includes: triggering a route change event based on the first route; In response to the route change event, a tracking point that matches the first route is determined from a preset tracking point module.
5. The method for collecting data based on routing according to claim 1, wherein: In response to the triggering of the target action, generating a historical record corresponding to the target action by using the rewritten historical record management rule includes: In response to triggering of the target action, obtaining routing parameters associated with the triggering of the target action; The plurality of routing parameters are merged, and based on the merged routing parameters, the historical record is generated by using the rewritten historical record management rule.
6. The method for collecting data based on routing according to claim 1, wherein: The method further comprises: In response to receiving the data reporting task, obtaining multiple unreported tracking data; The multiple unreported buried point data are merged and uploaded to the data server for storage.
7. The method for collecting data based on routing according to claim 1, wherein: The acquiring of multiple target behavior data generated by the user based on multiple target actions of a preset application includes: Acquire multiple actual behavior data generated by the user for multiple preset actions of the preset application, and acquire multiple calibrated behavior data of the preset actions; Comparing the plurality of actual behavior data with the plurality of calibration behavior data, and determining a plurality of target actions from the plurality of preset actions based on the comparison result; The calibrated behavior data corresponding to each target action is used as target behavior data.
8. A routing-based buried point data collection device, characterized in that: The buried point data acquisition device includes: A data acquisition module is used to acquire multiple target behavior data generated by multiple target actions of the user based on preset applications; A rule rewriting module, configured to rewrite the history record management rules of the preset application based on the plurality of target behavior data; a record generation module, configured to generate a historical record corresponding to the target action by using the rewritten historical record management rule in response to the triggering of the target action; A route determination module, configured to determine a first route corresponding to the historical record; The data collection module is used to collect data of the target page of the preset application based on the embedding point corresponding to the first route.
9. A computer device, characterized in that: The computer device includes a processor, a memory, and a computer program stored in the memory and executable by the processor, wherein when the computer program is executed by the processor, the routing-based point data collection method as described in any one of claims 1 to 7 is implemented.
10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by the processor, the routing-based point data collection method according to any one of claims 1 to 7 is implemented.