Embedded verification methods, devices, electronic equipment and storage media

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for tracking point verification. The method includes: inputting tracking point information, including version information, tracking point events, and tracking point attributes; running a tracking point triggering script embedded in a server, the script automatically triggering tracking point events; in response to an event triggered by the script, obtaining the tracking point attribute value corresponding to the tracking point attribute under the tracking point event; and verifying the tracking point attributes and their values ​​according to tracking point verification rules. The verification rules include scenario validation, used to verify whether the tracking point attributes and their values ​​under an operation path meet expectations. Using this application, automated tracking point verification can be achieved, enabling timely detection of non-standard tracking point data and prompt correction of issues causing non-standard tracking point data.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular to a method, apparatus, electronic device, computer-readable storage medium, and computer program product for data tracking and verification. Background Technology

[0002] In the era of big data, most web or app products use third-party or self-developed data systems to collect user behavior data and other information. Data tracking is a crucial part of this process. Data tracking involves collecting data within specific processes within the application to track usage and further optimize the product or provide operational data support. Examples of data collected include visit counts, click counts, dwell time, page views, and bounce rate. Validation of data tracking is paramount; accurate tracking is highly valuable for product design optimization, iteration direction selection, and achieving business goals.

[0003] Existing methods for tracking and verifying event tracking often involve manually performing the tracking after communication with technical personnel, and then manually verifying the accuracy of the data based on the tracking feedback. Manually verifying event tracking requires a large number of repeated clicks and one-to-one data comparisons, which is an extremely labor-intensive task and is also prone to errors. This not only involves a lot of repetitive work, but also consumes a significant amount of online resources.

[0004] Moreover, existing technologies for event tracking verification often cache the page to which the event occurred before it was generated, or a series of operation paths. This is a huge workload for developers and is intrusive to existing business logic.

[0005] In view of this, there is an urgent need for an automated method for data tracking verification, which addresses many problems in existing technologies. Summary of the Invention

[0006] In view of this, embodiments of this application provide a method, apparatus, electronic device, computer-readable storage medium, and computer program product for verifying embedded data points, in order to solve at least one technical problem.

[0007] This application provides a method for verifying event tracking, characterized by comprising: inputting event tracking information based on data requiring feedback, the event tracking information including: version information, page information, event tracking, and event tracking attributes; embedding a corresponding event tracking trigger script in the server according to the event tracking information, the event tracking trigger script being used to automatically trigger event tracking; running the event tracking trigger script embedded in the server; in response to the event tracking triggered by the event tracking trigger script, obtaining the event tracking attribute value corresponding to the event tracking attribute; and verifying the event tracking attributes and event tracking attribute values ​​according to event tracking verification rules; wherein, the event tracking verification rules include: scenario verification, used to verify whether the event tracking attributes and event tracking attribute values ​​under an operation path meet expectations.

[0008] Optionally, the scenario verification includes: determining the estimated value of the tracking attributes of all tracking points under an operation path, wherein the estimated value includes at least the operation order of the operation path; generating a tracking trigger script based on the operation path; running the tracking trigger script on the server; obtaining the tracking attributes and tracking attribute values ​​under an operation path; if the time order of the obtained series of tracking points is the same as the tracking attribute values ​​and the expected values, then the scenario verification is successful.

[0009] Optionally, the data reporting method in the scenario verification is non-real-time reporting.

[0010] Optionally, the tracking point verification rules include: integrity verification, used to verify whether the number of acquired tracking point attributes and tracking point attribute values ​​meets the requirements.

[0011] Optionally, the tracking point verification rules include: correctness verification, used to verify whether the data type, value range and / or regular expression of the attribute value meet the requirements.

[0012] Optionally, it further includes: if certain tracking points are not modified in the new version, the new version will inherit these tracking points from the old version after it goes live.

[0013] This application further includes a tracking point verification device, comprising: a tracking point input module for inputting tracking point information based on data requiring feedback, the tracking point information including: version information, page information, tracking point events, and tracking point attributes; a script embedding module for embedding a corresponding tracking point triggering script in the server according to the tracking point information, the tracking point triggering script being used to automatically trigger tracking point events; a script running module for running the tracking point triggering script embedded in the server; a data acquisition module for acquiring the tracking point attribute value corresponding to the tracking point attribute under the tracking point event in response to the tracking point event triggered by the tracking point triggering script; and a tracking point verification module for verifying the tracking point attributes and tracking point attribute values ​​according to tracking point verification rules; wherein the tracking point verification rules include: scene verification, used to verify whether the tracking point attributes and tracking point attribute values ​​under an operation path meet expectations.

[0014] This application provides an electronic device, which includes a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the steps of the method described above.

[0015] This application provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the steps of the method described above.

[0016] This application provides a computer program product, which includes computer program instructions that, when executed by a processor, implement the steps of the method described above.

[0017] According to embodiments of the present invention, a method and apparatus for event tracking verification, and a readable storage medium, the following steps are implemented: Based on the data requiring feedback, event tracking information is entered; a corresponding event tracking trigger script is embedded in the server; the embedded event tracking trigger script is run; in response to an event tracking event triggered by the event tracking trigger script, the event tracking attribute value corresponding to the event tracking attribute is obtained; and the event tracking attribute and its value are verified according to event tracking verification rules. This solution supports parallel implementation across multiple projects, versions, and channels. After a new version is released, new and old event tracking points are automatically merged, reducing unnecessary workload. Even if a version is delayed, resulting in some event tracking points not being released, the remaining points can be included in the next released version.

[0018] In the embodiments of this application, by running the event trigger script, events are automatically triggered, thereby obtaining the corresponding event event data, and the event tracking is automatically verified based on the event data. Compared with manual event tracking and verification by users, the method of automatically triggering events and verifying them through scripts eliminates the tedious process of manually triggering event tracking, thus saving labor costs and improving the efficiency of verifying event tracking data. Since the system can automatically verify the correctness of event tracking information, intuitively display the verification results of event tracking information, and save all statistical event tracking request records, it assists in the verification of statistical event tracking, thus further reducing the workload of testing and verification personnel.

[0019] In addition, data reporting can be done in a non-real-time manner. This reduces the workload of developers, mitigates the risk of business intrusion, and saves online resources. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings of the embodiments of this application will be briefly described below.

[0021] Figure 1 This is a schematic diagram of the system architecture of an embodiment of this application.

[0022] Figure 2 This is a flowchart of the data tracking verification method according to an embodiment of this application.

[0023] Figure 3 This is a flowchart illustrating the scene verification method according to an embodiment of this application.

[0024] Figure 4 This is a schematic diagram of the operation interface of an embodiment of this application.

[0025] Figure 5 This is a structural block diagram of the embedding verification device according to an embodiment of this application.

[0026] Figure 6 This is a schematic diagram of an electronic device used to implement the embedding verification method in the embodiments of this application. Detailed Implementation

[0027] The principles and spirit of this application will be described below with reference to several exemplary embodiments. It should be understood that these embodiments are provided to make the principles and spirit of this application clearer and more thorough, enabling those skilled in the art to better understand and implement the principles and spirit of this application. The exemplary embodiments provided herein are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments described herein without inventive effort are within the scope of protection of this application.

[0028] The embodiments of this application relate to terminal devices and / or servers. Those skilled in the art will understand that the embodiments of this application can be implemented as a system, apparatus, device, method, computer-readable storage medium, or computer program product. Therefore, this disclosure can be specifically implemented in at least one of the following forms: entirely hardware, entirely software, or a combination of hardware and software. According to the embodiments of this application, this application claims protection for a method, apparatus, electronic device, computer-readable storage medium, and computer program product for embedded verification. Figure 1 A schematic diagram of a system architecture according to an embodiment of this application is shown. For example... Figure 1 As shown, the system includes a terminal device 102 and a server 104. The terminal device 102 can include at least one of the following: a smartphone, tablet, laptop, desktop computer, smart TV, various wearable devices, augmented reality (AR) devices, virtual reality (VR) devices, etc. A client can be installed on the terminal device 102. For example, the client can be a client specifically designed to perform a particular function (such as an application app), or a client with multiple embedded application applets (with different functions), or a client logged in via a browser. Users can operate on the terminal device 102. For example, a user can open the client installed on the terminal device 102 and input commands through the client, or a user can open the browser installed on the terminal device 102 and input commands through the browser. After receiving the user's input command, the terminal device 102 sends a request message containing the command to the server 104. After receiving the request message, the server 104 performs the corresponding processing and then returns the processing result information to the terminal device 102. The user command is completed through a series of data processing and information interaction.

[0029] In this document, terms such as first, second, and third are used only to distinguish one entity (or operation) from another, and are not intended to require or imply any order or relationship between these entities (or operations).

[0030] The following is a brief description of the concepts and technical terms that may be involved in the embodiments of this application.

[0031] Event tracking or event tracking analysis is a common data collection method in website analytics. It refers to attaching data collection program code to the functional program code at the "operation node" where data needs to be collected, in order to capture, process, and send user behavior or events at the operation node.

[0032] In this field, existing methods for tracking and verifying event tracking often involve manual tracking operations performed after communication with technical personnel, followed by manual verification of the accuracy of the tracking data. Manually verifying event tracking requires a large number of repeated clicks and one-to-one data comparisons, which is extremely labor-intensive and prone to errors. This not only involves a lot of repetitive work but also consumes a significant amount of online resources.

[0033] Figure 2 The flowchart of the data tracking verification method according to an embodiment of this application is shown. The method includes the following steps:

[0034] S101: Based on the data that needs to be fed back, enter the tracking information, which includes: version information, page information, tracking events, and tracking attributes.

[0035] S102: Based on the event tracking information, embed the corresponding event tracking trigger script in the server. The event tracking trigger script is used to automatically trigger event tracking events.

[0036] S103: Run the event trigger script embedded in the server.

[0037] S104: In response to an event triggered by the event triggering script, obtain the event attribute value corresponding to the event attribute.

[0038] S105: Verify the tracking point attributes and their values ​​according to the tracking point verification rules. The tracking point verification rules include: scene verification, used to verify whether the tracking point attributes and their values ​​under an operation path meet expectations.

[0039] According to the processing method of this application embodiment, events can be automatically triggered by running the event tracking script as needed, thereby obtaining the event-related event tracking data. Then, the correctness of the event tracking data is automatically verified through scene validation. Compared with the method of triggering events through manual user operation, the method of automatically triggering and verifying events through scripts eliminates the tedious process of manually triggering and verifying event tracking, thus saving labor costs and improving the efficiency of verifying event tracking data.

[0040] For example, you can create a task in the management backend that is associated with a series of tracking points, in a specific order, such as three tracking points A, B, and C. You can individually set the attribute values ​​for each tracking point in this scenario. After setting these, edit the task's script. Using the script, clicking Button A, Button B, and Button C in sequence will generate tracking points A, B, and C. After the task completes, upload the tracking point data for validation. If the timing of tracking points A, B, and C is not in the prescribed order, the validation will fail.

[0041] The reason for this approach is to provide feedback on the data from a specific operation path (e.g., clicking a button, navigating to another page, and then performing subsequent operations) to analyze whether there are any issues with the data from that operation path.

[0042] In other words, the embodiments of this application do not only feed back data from a single button or page, but can feed back data from a series of related operations together, thus obtaining data for this operation path.

[0043] The advantage of this approach is that traditional tracking data feedback, presented as a single piece of data, can only indicate whether its own function is complete. However, if problems arise in the interconnected functions of multiple operations, this cannot be known through a single piece of data. Only by obtaining data along this entire operation path can we determine whether the data between operations meets expectations.

[0044] Furthermore, for manual clicks, for example, if there's a button A on a page, clicking the button will generate an event tracking point. This event tracking point has a `pageCode` attribute, which is a fixed value of `xxxx`. If the uploaded event tracking point's `pageCode` attribute is not equal to `xxxx`, the validation will fail. This method is time-consuming, labor-intensive, and has low accuracy. Automated validation, on the other hand, sets the attribute value of event tracking point A separately for this scenario, for example, `pageCode = xxxx`. After setting it, the script for this task is edited. Clicking sequentially and judging from the feedback data, if the validation fails (e.g., the `pageCode` attribute of event tracking point A is not equal to `xxx`), the validation fails.

[0045] According to embodiments of this application, optionally, scene verification includes:

[0046] S201: Determine the estimated value of the tracking attributes of all tracking points under an operation path, wherein the estimated value includes at least the operation order of the operation path.

[0047] S202: Generate a tracking script based on the operation path.

[0048] S203: Run the event tracking script on the server.

[0049] S204: Obtain the tracking attributes and tracking attribute values ​​under an operation path; if the time order of the obtained attribute values ​​is the same as the operation order of the estimated value of the tracking attributes, then the scenario verification is successful.

[0050] This application can automatically trigger the tracking attributes and their values ​​under an operation path that needs to be verified by using a script. This not only improves efficiency but also increases accuracy, avoiding potential human error.

[0051] Optionally, according to an embodiment of this application, the data reporting method in the scenario verification is non-real-time reporting.

[0052] Real-time data reporting increases server load because the server is also performing related operations while verification is being conducted. Separating the operation time from the data reporting time can reduce the server load.

[0053] Optionally, according to an embodiment of this application, the tracking point verification rules include:

[0054] Integrity verification is used to verify whether the number of obtained tracking point attributes and tracking point attribute values ​​meets the requirements.

[0055] In the embodiments of this application, completeness can also be verified. For example, whether the data entry has extra or missing fields. For instance, if the field "name=xxx" is added, the verification will fail. If there are supposed to be 10 data entry points, but 11 are added, the verification will also fail. The various verification methods can ensure the accuracy of the verification from multiple perspectives.

[0056] Optionally, according to an embodiment of this application, the tracking point verification rules include:

[0057] Correctness verification is used to verify whether the data type, value range, and / or regular expression of the attribute value meet the requirements.

[0058] In the embodiments of this application, correctness can also be verified. For example, data type: if the jobId is defined as an Int type, but the result is a String type, the verification will fail. Enumeration range: if the given range is 0-9, but the result is 10, the verification will fail. Regular expression: if the given regular expression is 0-9, but the result is 10, the verification will fail. This step can be performed using JSON Scheme for compliance verification. With various verification methods, the accuracy of verification can be guaranteed from multiple aspects.

[0059] According to an embodiment of this application, optionally, if certain tracking points are not modified in the new version, the new version will inherit these tracking points from the old version after it is launched.

[0060] When a version is updated, many tracking points are not abandoned with the update, and this data often needs to be continuously collected. Inheriting tracking points from previous versions can increase tracking point utilization and work efficiency, and reduce repetitive work.

[0061] The implementation methods and advantages of the embodiments of this application have been described above through multiple examples. The specific processing procedures of the embodiments of this application are described in detail below with reference to specific examples.

[0062] like Figure 4The interface shown is as follows. In one scenario, the person responsible for the product (e.g., the product manager) might request specific event tracking points or data from the operations team (e.g., the data team). After confirming the release version, a version number can be selected. Channels can also be selected, such as PC, App, or Mini Program. Different channels can have separate version numbers. If the product team has version numbers, such as for iOS and Android, those version numbers can be used. If there is no version concept, such as for PC, the data team can design version numbering rules. In some embodiments, the referenced version refers to a version already released on a specific channel. After the data team refines the event tracking scheme, the system will automatically list any new and modified event tracking schemes that need to be developed compared to the referenced version.

[0063] After confirming the relevant requirements, the event tracking points need to be entered. First, select the page to be tracked, confirming the specific project name, channel, version number, and page information. Then, enter the event tracking requirements on that page. During the entry process, you can select version information, page information, event tracking points, and event tracking attributes. Page information is used to locate the specific page for which event tracking points are set. Event tracking points are used to distinguish which type of event the tracking point is for, such as login, send, or share events. Event tracking attributes are used to record which attributes the tracking point includes, such as user ID, page ID, and user type.

[0064] In some embodiments, if the page is a new page, the page can be added first, and then the tracking operation can be performed.

[0065] To add event tracking points, you can select them by entering the information or by using a selection box. If multiple buttons need to report the same event, you can use the selection box function to select one button (the event will be added to the list page), and then click "Multiple Selection" in the new event operation bar to add a new selection box with the same identifier as the existing one.

[0066] After selecting an event, you can modify or edit the selected content. Specifically: View / Edit: Clicking this will open the event tracking request details page for editing attributes. Full event tracking automatically includes common attributes; only custom event tracking requires attribute maintenance. Delete Box: Clears the selection of the event tracking. A full event tracking request must have at least one selection to be considered complete. Delete: Deletes unnecessary event tracking requests. Offline: Event tracking that has been published but is no longer needed in later versions can be requested for removal using this button. Migrate: Moves the event tracking request to another page.

[0067] After the event tracking data is entered, once the version is released, the scripts related to the entered tracking data will be manually triggered or timers will be automatically started on various platforms (App or PC) to trigger the collection of relevant event tracking data. Once the relevant event tracking data is collected, automatic verification can be performed.

[0068] The verification includes: integrity, data correctness, and scenario verification. In some embodiments, integrity and data correctness verification are reported in real time. In some embodiments, scenario verification is reported non-real time. In some embodiments, data is integrated through the Sensors Analytics SDK and reported via socket.

[0069] Integrity check: For example, whether the data of this tracking point has too many or too few fields. For example, if the field name=xxx is added, the check will fail. If there are supposed to be 10 tracking points, but 11 are added, the check will fail.

[0070] Correctness verification: Data type: If the jobId is defined as an Int type, but the result is a String type, the verification will fail. Enumeration range: For example, if the given range is 0-9, but the result is 10, the verification will fail. Regular expression: If the given regular expression is 0-9, but the result is 10, the verification will fail. This step can be performed using JSON Scheme for compliance verification.

[0071] Scenario Validation: Manual Click: For example, if there's a button A on the page, clicking it will generate an event tracking point. This tracking point has a `pageCode` attribute, which is a fixed value of `xxxx`. If the uploaded tracking point's `pageCode` attribute is not equal to `xxxx`, the validation will fail. Automated Click: Create a task in the management backend, associating it with a series of tracking points in a specific order. For example, tracking points A, B, and C. We can set the attribute value of tracking point A individually for this scenario, such as `pageCode = xxxx`. After setting this, edit the task's script. Clicking Button A, Button B, and Button C in sequence will generate tracking points A, B, and C. After the task completes, upload the tracking points for validation. If the timing of tracking points A, B, and C is not in the specified order, the validation will fail. For example, if the `pageCode` attribute of tracking point A is not equal to `xxx`, the validation will fail.

[0072] Before verification, we first need to obtain the event tracking verification rules (the rules we entered). The event tracking verification rule selection will be based on the key information in the event tracking data, selecting the corresponding event tracking verification rule from the verification rule data table. Matching rules will be filtered from the verification rule data table based on $app_version and event element_id in the event tracking data.

[0073] The event tracking verification will verify the event tracking data and generate verification results based on the basic verification rules and the event tracking verification rules generated by the rule selector.

[0074] In some embodiments, the data fed back from the tracking points can be compared with the expected data during the verification process to automate the tracking point verification.

[0075] In some embodiments, the generation of expected data mainly includes event ID, format, type, value range, and scenario of specific fields. The collection of expected data is mainly divided into two situations: one is manual entry, which involves creating rules through the platform to impose constraints and limitations, suitable for scenarios where new tracking points are added later; the other is analysis of existing data, which involves analyzing the attributes and rules of existing tracking point data through online crawling, document import, and other methods, or generating expected data based on the inherent patterns of the data itself.

[0076] In some embodiments, the data that needs to be verified is compared by the platform to generate a verification test report.

[0077] The prediction results can be shown below:

[0078] {

[0079] version:13.0.0,

[0080] event:$AppClick, / / Event name

[0081] elementId:chatButton, / / ID of the event tracking element

[0082] scene:{"from":"session|session|sessionjoblist","name":"IM chat details page"}, / / Used for rule selector

[0083] physical_validation:"JSONScheme" (see the code above for converting JSON objects to strings), / / used for event tracking validation

[0084] }

[0085] Corresponding to the method embodiments of this application, this application also provides a device for verifying embedded points, such as... Figure 5 As shown, the embedded verification device 100 includes:

[0086] The event tracking module 110 is used to input event tracking information based on the data that needs to be fed back. The event tracking information includes: version information, page information, event tracking events, and event tracking attributes.

[0087] The script embedding module 120 embeds a corresponding event triggering script in the server according to the event tracking information. The event triggering script is used to automatically trigger event tracking events.

[0088] Script execution module 130 runs the embedded tracking script in the server.

[0089] The data acquisition module 140, in response to the tracking event triggered by the tracking event triggering script, acquires the tracking attribute value corresponding to the tracking attribute under the tracking event.

[0090] The tracking point verification module 150 verifies the tracking point attributes and tracking point attribute values ​​according to the tracking point verification rules; wherein, the tracking point verification rules include: scene verification, used to verify whether the tracking point attributes and tracking point attribute values ​​under an operation path meet expectations.

[0091] According to embodiments of the present invention, a method and apparatus for event tracking verification, and a readable storage medium, the following steps are implemented: Based on the data requiring feedback, event tracking information is entered; a corresponding event tracking trigger script is embedded in the server; the embedded event tracking trigger script is run; in response to an event tracking event triggered by the event tracking trigger script, the event tracking attribute value corresponding to the event tracking attribute is obtained; and the event tracking attribute and its value are verified according to event tracking verification rules. This solution supports parallel implementation across multiple projects, versions, and channels. After a new version is released, new and old event tracking points are automatically merged, reducing unnecessary workload. Even if a version is delayed, resulting in some event tracking points not being released, the remaining points can be included in the next released version.

[0092] The electronic device in this application embodiment may be a user terminal device, a server, other computing devices, or a cloud server. Figure 6 The diagram illustrates the hardware structure of an electronic device according to an embodiment of this application. The electronic device may include a processor 601 and a memory 602 storing computer program instructions. When the processor 601 executes the computer program instructions, it implements the process or function of any of the methods described above.

[0093] Specifically, processor 601 may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application. Memory 602 may include mass storage for data or instructions. For example, memory 602 may be at least one of the following: hard disk drive (HDD), read-only memory (ROM), random access memory (RAM), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, universal serial bus (USB) drive, or other physical / tangible memory storage device. Alternatively, memory 602 may include removable or non-removable (or fixed) media. Furthermore, memory 602 may be internal or external to the integrated gateway disaster recovery device. Memory 602 may be non-volatile solid-state memory. In other words, typically memory 602 includes a tangible (non-transitory) computer-readable storage medium (such as a memory device) encoded with computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in the methods of the embodiments of this application. The processor 601 implements the process or function of any of the methods described in the above embodiments by reading and executing computer program instructions stored in the memory 602.

[0094] In one example Figure 6 The illustrated electronic device may also include a communication interface 603 and a bus 610. The processor 601, memory 602, and communication interface 603 are connected via bus 610 and communicate with each other. Communication interface 603 is primarily used to enable communication between modules, devices, units, and / or equipment in the embodiments of this application. Bus 610 may include hardware, software, or both, and can couple components of the online data traffic billing device together. For example, the bus may include at least one of the following: Accelerated Graphics Port (AGP) or other graphics bus, Enhanced Industry Standard Architecture (EISA) bus, Front Side Bus (FSB), HyperTransport (HT) Interconnect, Industry Standard Architecture (ISA) bus, Infinite Bandwidth Interconnect, Low Pin Count (LPC) bus, memory bus, Microchannel Architecture (MCA) bus, Peripheral Component Interconnect (PCI) bus, PCI-Express (PCI-X) bus, Serial Advanced Technology Attachment (SATA) bus, Video Electronics Standards Association Local (VLB) bus, or other suitable buses. Bus 610 may include one or more buses. Although specific buses are described or illustrated in the embodiments of this application, any suitable bus or interconnection method may be considered in the embodiments of this application.

[0095] In conjunction with the methods in the above embodiments, this application also provides a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the process or function of any of the methods in the above embodiments.

[0096] In addition, this application also provides a computer program product that stores computer program instructions, which, when executed by a processor, implement the process or function of any of the methods described above.

[0097] The flowcharts and / or block diagrams of methods, apparatuses, systems, and computer program products according to embodiments of this application have been exemplarily described above, and related aspects have been described. It should be understood that each block or combination thereof in the flowcharts and / or block diagrams may be implemented by computer program instructions, by dedicated hardware performing a specified function or action, or by a combination of dedicated hardware and computer instructions. For example, these computer program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to form a machine that enables the implementation of the function / action specified in each block or combination thereof in the flowcharts and / or block diagrams, executable via such processor. Such a processor may be a general-purpose processor, a dedicated processor, a special-purpose application processor, or a field-programmable logic circuit.

[0098] The functional blocks shown in the structural block diagrams of this application can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc.; when implemented in software, they are programs or code segments used to perform the required tasks. Programs or code segments can be stored in memory or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. Code segments can be downloaded via computer networks such as the Internet or intranets.

[0099] It should be noted that this application is not limited to the specific configurations and processes described above or shown in the figures. The above descriptions are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the described systems, devices, modules, or units can be referred to the corresponding processes in the method embodiments, and need not be repeated here. It should be understood that the scope of protection of this application is not limited thereto. Any person skilled in the art can conceive of various equivalent modifications or substitutions within the scope of the technology disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application.

Claims

1. A data tracking system based on interface selection interaction, characterized in that, include: The event tracking confirmation unit is used to select the page to be tracked based on the desired event tracking or data information, and to confirm the project name, channel, version number, and page information. The event tracking entry unit is used to enter event tracking requirements on the selected page. During the entry process, version information, page information, event tracking, and event tracking attributes are selected. Page information is used to locate the page for which event tracking is to be set, event tracking is used to distinguish the type of event for which the event tracking is used, and event tracking attributes are used to record the attributes contained in the event tracking. If the page is a new page, it is added first, and then the event tracking operation is performed. The event tracking entry unit includes: The event tracking sub-unit is used to add event tracking points by input or selection. If multiple buttons need to report the same event, select the selection function to select a button, and then select multiple selections in the new event operation bar to add a new selection with the same identifier as the existing selection. The added event tracking points include multiple event tracking points associated with the same task, and these multiple event tracking points have a specific order. The event tracking editing sub-unit is used to open the event tracking requirement details page by clicking after selecting the event tracking points to modify or edit the selected content. If the event tracking is full tracking, the common attributes will be automatically carried after the event tracking points are entered. The script embedding unit is used to embed the corresponding event triggering script in the server according to the event tracking information. The event triggering script is used to automatically trigger event tracking events. The script execution unit is used to run the embedded event trigger scripts in the server. The event tracking acquisition unit is used to acquire the event tracking attribute value corresponding to the event tracking attribute in response to the event tracking event triggered by the event tracking triggering script. The event tracking verification unit is used to verify the event tracking attributes and event tracking attribute values ​​according to event tracking verification rules; the event tracking verification rules include: scenario verification, used to verify whether the event tracking attributes and event tracking attribute values ​​under an operation path meet expectations; the scenario verification includes: Determine the estimated value of the tracking attributes of all tracking points under an operation path, wherein the estimated value includes at least the operation order of the operation path; generate a tracking trigger script based on the operation path and run the tracking trigger script on the server; obtain the tracking attributes and tracking attribute values ​​under an operation path, and feed back the data of a series of related operations under an operation path to obtain the data of this operation path; if the time order of the obtained series of tracking points is the same as the attribute values ​​and expected values ​​of each tracking point, then the scenario verification is successful. If some tracking points are not modified in the new version, the new version will inherit these tracking points from the old version after it goes live, so as to continuously obtain the data reported by these tracking points.

2. The system according to claim 1, characterized in that, The data reporting method in the scenario verification is non-real-time reporting.

3. The system according to claim 1, characterized in that, The tracking point verification rules also include: Integrity verification is used to verify whether the number of obtained tracking point attributes and tracking point attribute values ​​meets the requirements.

4. The system according to claim 1, characterized in that, The tracking point verification rules also include: Correctness verification is used to verify whether the data type, value range, and / or regular expression of the attribute value meet the requirements.

5. An electronic device comprising a processor and a memory storing computer program instructions; wherein the processor, when executing the computer program instructions, implements the system as described in any one of claims 1-4.

6. A computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the system as described in any one of claims 1-4.

7. A computer program product comprising computer program instructions that, when executed by a processor, implement the system as described in any one of claims 1-4.

Images