Data burying point request method and device, storage medium and electronic equipment

Abstract

The invention discloses a data burying point request method and device, a storage medium and electronic device.The data burying point request method comprises the steps that when a burying point event is monitored, the burying point event is stored in a local cache queue; pre-processing the buried point events in the local cache queue, and sorting the processed buried point events according to a preset priority rule; when a preset condition is established, packaging the processed burying point event to generate a burying point data packet; and sending a burying point data request carrying the burying point data packet to a server. According to the scheme, the data reliability can be improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and specifically to a data embedding request method, device, storage medium and electronic device. Background Art

[0002] Tracking refers to collecting some information in a specific process in an application (APP) to track the usage of the application, which can be used to further optimize the product or provide data support for operations. Tracking can be used to collect information such as the number of visits, number of visitors, length of stay, number of page views, bounce rate, etc.

[0003] Currently, data tracking requests mainly use two strategies: scheduled sending and event-triggered sending. However, although the event-triggered sending strategy ensures the real-time reporting of key event data, issuing network requests when users are actively interacting may cause application response delays and affect user experience. The scheduled sending strategy cannot take into account the real-time network status of the device and the real-time load of the server. It may send data when the network status is poor or the server load is too high, resulting in data loss. In other words, the current data tracking request strategy is difficult to guarantee the reliability of data. Summary of the invention

[0004] The embodiments of the present application provide a data embedding request method, device, storage medium and electronic device, which can improve the reliability of data.

[0005] In a first aspect, an embodiment of the present application provides a data burying request method, including:

[0006] When a tracking event is detected, the tracking event is stored in a local cache queue;

[0007] Preprocessing the tracking events in the local cache queue, and sorting the processed tracking events according to a preset priority rule;

[0008] When the preset conditions are met, the processed tracking events are packaged to generate tracking data packets;

[0009] A burying point data request carrying the burying point data packet is sent to the server.

[0010] In the data tracking request method provided in the embodiment of the present application, the preset conditions are met including:

[0011] The number of the burying point events in the local cache queue reaches a preset threshold, or the storage time of the burying point events in the local cache queue reaches a preset time threshold.

[0012] In the data tracking request method provided in the embodiment of the present application, the preset conditions are met including:

[0013] The electronic device is detected to be idle and / or the network condition is good.

[0014] In the data tracking request method provided in the embodiment of the present application, preprocessing the tracking event in the local cache queue includes:

[0015] The tracking events in the local cache queue are filtered to eliminate invalid or repeated tracking events.

[0016] In the data tracking request method provided in the embodiment of the present application, the processing of the tracking event is packaged to generate a tracking data packet, including:

[0017] Performing statistics on the processed embedding events to generate statistical results;

[0018] The statistical results and the buried point events are organized according to a preset data structure to form a buried point data packet.

[0019] In the data tracking request method provided in the embodiment of the present application, the processing of the tracking events is counted to generate statistical results, including:

[0020] Obtain the event type, event parameters, event result and user profile of the event;

[0021] Statistics are collected on the buried event type, the buried event parameters, the buried event results and the user portrait to generate statistical results.

[0022] In the data burying point request method provided in the embodiment of the present application, after forming the burying point data packet and before sending the burying point data request carrying the burying point data packet to the server, it also includes:

[0023] The burying point data request carrying the burying point data packet is encrypted.

[0024] In a second aspect, an embodiment of the present application provides a data embedding request device, including:

[0025] A monitoring unit, configured to store a buried point event in a local cache queue when a buried point event is detected;

[0026] A processing unit, used to pre-process the tracking events in the local cache queue and sort the processed tracking events according to a preset priority rule;

[0027] A packaging unit, used for packaging the processed tracking event to generate a tracking data packet when a preset condition is met;

[0028] The sending unit is used to send a burying point data request carrying the burying point data packet to the server.

[0029] In a third aspect, the present application provides a storage medium storing a plurality of instructions suitable for loading by a processor to execute any of the data embedding request methods described above.

[0030] In a fourth aspect, the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements any of the above-described data embedding request methods when executing the computer program.

[0031] In summary, the data burying point request method provided in the embodiment of the present application includes storing the burying point event in a local cache queue when a burying point event is monitored; preprocessing the burying point event in the local cache queue, and sorting the processed burying point events according to preset priority rules; packaging the processed burying point event to generate a burying point data packet when preset conditions are met; and sending a burying point data request carrying the burying point data packet to the server. This solution can improve data processing efficiency through local cache queues and priority rules, and only sends a burying point data request carrying the burying point data packet to the server when preset conditions are met, thereby ensuring data integrity and improving data reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0033] Figure 1 It is a structural diagram of the data embedding request system provided in an embodiment of the present application.

[0034] Figure 2 It is a flow chart of the data embedding request method provided in an embodiment of the present application.

[0035] Figure 3 It is a structural diagram of the data embedding request device provided in an embodiment of the present application.

[0036] Figure 4 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0038] It should be noted that, in this article, the terms "include", "comprises" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "includes a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element. In addition, components, features, and elements with the same name in different embodiments of the present application may have the same meaning or different meanings, and their specific meanings need to be determined by their explanation in the specific embodiment or further combined with the context of the specific embodiment.

[0039] It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0040] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application, and have no specific meanings. Therefore, "module", "component" or "unit" can be used in a mixed manner.

[0041] In the description of the present application, it should be noted that the terms "upper", "lower", "left", "right", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present application. In addition, terms such as "first" and "second" are only used for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0042] Currently, data tracking requests mainly use two strategies: scheduled sending and event-triggered sending. However, although the event-triggered sending strategy ensures the real-time reporting of key event data, issuing network requests when users are actively interacting may cause application response delays and affect user experience. The scheduled sending strategy cannot take into account the real-time network status of the device and the real-time load of the server. It may send data when the network status is poor or the server load is too high, resulting in data loss. In other words, the current data tracking request strategy is difficult to guarantee the reliability of data.

[0043] Based on this, the embodiments of the present application provide a data embedding request method, device, storage medium and electronic device. Specifically, the data embedding request device can be integrated in an electronic device, which can be a server or a terminal; wherein the terminal can include a mobile phone, a wearable smart device, a tablet computer, a laptop computer, and a personal computer (PC); the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0044] See also Figure 1 , Figure 1 A structural diagram of a data point request system provided in an embodiment of the present application. The system may include at least one electronic device 1000, at least one server or personal computer 2000. The electronic device 1000 held by the user can be connected to different servers or personal computers through a network. The electronic device 1000 may be an electronic device with computing hardware that can support and execute software products corresponding to multimedia. In addition, the electronic device 1000 may also have one or more multi-touch screens for sensing and obtaining the input of the user through touch or sliding operations performed at multiple points on one or more touch-sensitive display screens. In addition, the electronic device 1000 can be interconnected with the server or personal computer 2000 through a network. The network may be a wireless network or a wired network, such as a wireless network such as a wireless local area network (WLAN), a local area network (LAN), a cellular network, a 2G network, a 3G network, a 4G network, a 5G network, etc. In addition, different electronic devices 1000 can also use their own Bluetooth network or hotspot network to connect to other embedded platforms or to servers and personal computers, etc.

[0045] Among them, the electronic device includes a touch display screen and a processor, and the touch display screen is used to present a graphical user interface and receive operation instructions generated by the user acting on the graphical user interface. When the user operates the graphical user interface through the touch display screen, the graphical user interface can control the local content of the electronic device by responding to the received operation instructions, and can also control the content of the server side by responding to the received operation instructions. For example, the operation instructions generated by the user acting on the graphical user interface include instructions for processing the initial audio signal, and the processor is configured to start the corresponding application after receiving the instructions provided by the user. In addition, the processor is configured to render and draw a graphical user interface associated with the application on the touch display screen. The touch display screen is a multi-touch sensitive screen that can sense touch or sliding operations performed simultaneously at multiple points on the screen. The user uses a finger to perform a touch operation on the graphical user interface, and when the graphical user interface detects the touch operation, the corresponding operation is displayed in the graphical user interface of the control application.

[0046] The technical solutions shown in the present application will be described in detail below through specific embodiments. It should be noted that the description order of the following embodiments is not intended to limit the priority order of the embodiments.

[0047] See also Figure 2 , Figure 2 : is a flow chart of the data burying point request method provided in the embodiment of the present application. The specific process of the data burying point request method can be as follows:

[0048] 101. When a tracking event is detected, the tracking event is stored in a local cache queue.

[0049] During the specific implementation process, the tracking events can be monitored through page tracking, logic tracking, and native application tracking.

[0050] For example, page tracking: inserting monitoring code into the page to monitor user behavior events; logic tracking: adding monitoring code into the business logic to record key business events; native application tracking: embedding monitoring code into native applications to record user behavior on mobile devices.

[0051] The above-mentioned event monitoring method can be applied to various fields, such as the Internet industry: used to monitor user behavior of websites, apps and other products to optimize product design and improve user experience; financial industry: used to monitor user operations on financial platforms to prevent risks and improve service quality; retail industry: used to monitor user shopping behavior in retail stores to improve store operating efficiency and sales; education industry: used to monitor students' learning behavior on learning platforms to personalize recommendations of learning resources and services.

[0052] In order to ensure the integrity and accuracy of the data, the embodiment of the present application adopts a local data cache strategy, which means that whenever a buried event is detected, the buried event will be stored in the local cache queue at the same time.

[0053] It should be noted that the monitoring code can be deployed on the server or client and can be configured according to business needs. In the specific implementation process, the collection and processing of buried events can be viewed in real time through the monitoring system to ensure data accuracy.

[0054] 102. Pre-process the tracking events in the local cache queue, and sort the processed tracking events according to preset priority rules.

[0055] Specifically, the tracking events in the local cache queue can be filtered to remove invalid or repeated tracking events, and then the processed tracking events are sorted according to the preset priority rules.

[0056] Among them, the preset priority rule can be determined according to the following factors:

[0057] (1) Types of tracking events: Different types of tracking events have different priorities. For example, core business events such as user login and product purchase have higher priorities, while general events such as page views and ad clicks have lower priorities.

[0058] (2) Frequency of occurrence of tracking events: Tracking events with higher frequency have lower priority to avoid burdening the server by sending data packets frequently.

[0059] (3) Urgency of the tracking event: Urgent events that affect user experience and cause business abnormalities have a higher priority.

[0060] (4) User behavior habits: When a user does not have a specific tracking event for a long time, the priority of the corresponding tracking event increases.

[0061] It should be noted that you can customize tracking strategies and priority rules according to business needs to increase the flexibility of the system. At the same time, it can support multi-field and multi-scenario applications to meet the actual needs of different businesses.

[0062] 103. When the preset conditions are met, the processed tracking events are packaged to generate tracking data packets.

[0063] In some embodiments, the preset condition may be met when the number of buried events in the local cache queue reaches a preset threshold, or when the storage time of the buried events in the local cache queue reaches a preset time threshold.

[0064] In one embodiment, the os_activity framework can be used to obtain the running status of the application in the foreground and whether any user interaction occurs. When it is detected that the application is in the foreground and there is no user interaction for a period of time, the electronic device can be in an idle state at this time. In order to further improve the success rate of data embedding requests, the network connection status and speed of the electronic device can also be obtained in real time through iOS's Network.framework, and it is determined that the data embedding request is only sent when the network condition is good, thereby avoiding data loss and request failure. That is, the preset condition is established when it is detected that the electronic device is in an idle state and / or the network condition is good.

[0065] In some embodiments, the processed tracking events can be counted to generate statistical results, and the statistical results and tracking events can be organized according to a preset data structure to form a tracking data packet, so that the server can parse and process it later.

[0066] It should be noted that the preset data structure refers to a format with clear field definitions, which is used to organize tracking events and statistical results. The following takes the example that the preset data structure can be a JSON format data structure to explain in detail the formation process of the tracking data packet. Specifically, the specific process of forming the tracking data packet can be as follows:

[0067] First, you can create a top-level object to contain all relevant information. In the top-level object, you can add a field to store detailed information about the embedded event. For example, the field can be named events, which is an array that can contain multiple embedded event objects.

[0068] Each tracking event object may include the following fields:

[0069] event_id: a unique identifier used to distinguish different buried events;

[0070] timestamp: the time when the event occurred, usually in ISO 8601 format;

[0071] event_type: describes the type of event, such as "click" or "view";

[0072] event_params: contains event-related parameters, usually expressed in the form of key-value pairs, such as button ID, page URL, etc.

[0073] event_result: records the result of the event, such as "success" or "failure";

[0074] user_profile: Contains basic information about the user, such as user ID, device type, and geographic location.

[0075] After that, you can add a field in the top-level object to store the statistical results. The field can be named statistics. This field is an object that contains multiple statistical indicators, for example:

[0076] total_events: the total number of all buried events;

[0077] success_count: the number of successful events;

[0078] failure_count: the number of failed events;

[0079] average_duration: The average duration of the event.

[0080] In the above way, the JSON format data structure can clearly organize the tracking events and statistical results to form a tracking data package.

[0081] Among them, statistics are collected on the processed tracking events to generate statistical results, which can be specifically: obtaining the tracking event type, tracking event parameters, tracking event results and user portraits of the tracking events; collecting statistics on the tracking event type, tracking event parameters, tracking event results and user portraits to generate statistical results. The statistical results can be visualized in the form of charts, reports, etc., which is convenient for intuitive analysis and interpretation.

[0082] Among them, the tracking event type can distinguish different types of tracking events. Tracking event parameters can record the relevant parameters of the tracking event, such as time, location, user ID, etc. Tracking event results can record the results of the tracking event, such as successful purchase, failed login, etc. User portraits are user feature descriptions that can be generated based on user behavior data. By real-time statistics of user behavior data, it can provide a basis for business decisions, and can also provide users with personalized function recommendation services based on user behavior data.

[0083] In some embodiments, when statistics are collected on the buried event type, buried event parameters, buried event results, and user portraits, the specific statistics may be as follows:

[0084] Statistics are collected on the types of embedded point events, specifically, the number of different types of embedded point events can be counted, such as the number of click events, the number of page view events, etc.

[0085] Statistics are collected on the event parameters, specifically, the number and distribution of different event parameters can be counted, such as the number of clicks on different buttons, the URLs of visited pages, etc.

[0086] Statistics are collected on the results of tracking events. Specifically, the number of event results can be counted, such as the ratio of successful events to failed events.

[0087] Collect statistics on user portraits, specifically counting the number of different user groups, such as the number of groups grouped by device type, geographic location, or user ID.

[0088] It should be noted that in the actual application process, the tracking point strategy, priority rules, etc. are regularly adjusted and optimized according to business development needs.

[0089] 104. Send a point-of-sale data request carrying a point-of-sale data packet to the server.

[0090] In some embodiments, before sending the buried point data request carrying the buried point data packet to the server, the buried point data request carrying the buried point data packet may also be encrypted to ensure the security of the data. Among them, when encrypting the buried point data request, the encryption algorithm used may be a symmetric encryption or an asymmetric encryption algorithm, such as the Advanced Encryption Standard (AES) or RSA (Rivest-Shamir-Adleman). In actual application, a suitable encryption algorithm may be selected according to security requirements, and the embodiments of the present application do not limit it.

[0091] It is understandable that after receiving the burying point data request, the server can decrypt the encrypted burying point data request to obtain the original burying point data packet.

[0092] Afterwards, the server can parse the tracking data packets to extract tracking events and related information; then, based on the extracted information, analyze user behavior to explore potential needs and problems; and based on the analysis results, provide users with personalized services or optimize the performance of websites and applications.

[0093] In summary, the data burying point request method provided in the embodiment of the present application includes storing the burying point event in the local cache queue when the burying point event is monitored; preprocessing the burying point event in the local cache queue, and sorting the processed burying point events according to the preset priority rules; packaging the processed burying point event to generate a burying point data packet when the preset conditions are met; and sending a burying point data request carrying the burying point data packet to the server. This solution can improve data processing efficiency through the local cache queue and priority rules, and only sends the burying point data request carrying the burying point data packet to the server when the preset conditions are met, thereby ensuring the integrity of the data and improving the reliability of the data.

[0094] In order to facilitate better implementation of the data embedding request method provided in the embodiment of the present application, the embodiment of the present application also provides a data embedding request device. The meanings of the terms are the same as those in the above-mentioned data embedding request method, and the specific implementation details can refer to the description in the method embodiment.

[0095] See also Figure 3 , Figure 3 201 is a schematic diagram of the structure of the data point request device provided in the embodiment of the present application. The data point request device may include a monitoring unit 201, a processing unit 202, a packaging unit 203 and a sending unit 204.

[0096] The monitoring unit 201 is used to store the burying point event in a local cache queue when a burying point event is monitored.

[0097] The processing unit 202 is used to pre-process the tracking events in the local cache queue and sort the processed tracking events according to a preset priority rule.

[0098] The packing unit 203 is used to pack the processed burying point events and generate a burying point data packet when a preset condition is met.

[0099] The sending unit 204 is used to send a burying point data request carrying a burying point data packet to the server.

[0100] The specific implementation methods of the above-mentioned units can be found in the above-mentioned data embedding request method embodiment, which will not be described one by one here.

[0101] In summary, the data burying point request device provided in the embodiment of the present application can store the burying point event in the local cache queue through the monitoring unit 201 when the burying point event is monitored. The processing unit 202 pre-processes the burying point events in the local cache queue, and sorts the processed burying point events according to the preset priority rules. When the preset conditions are met, the packaging unit 203 packages the processed burying point events to generate a burying point data packet. The sending unit 204 sends the burying point data request carrying the burying point data packet to the server. This scheme can improve data processing efficiency through the local cache queue and priority rules, and only sends the burying point data request carrying the burying point data packet to the server when the preset conditions are met, thereby ensuring the integrity of the data and improving the reliability of the data.

[0102] The present application also provides an electronic device, in which the data embedding request device of the present application can be integrated, such as Figure 4As shown, it shows a structural schematic diagram of an electronic device involved in an embodiment of the present application, and the electronic device includes a memory 301, a processor 302, and a computer program stored in the memory 301 and executable on the processor 302, wherein the processor 302 implements the above-mentioned data embedding request method in the embodiment of the present application when executing the computer program.

[0103] In the above embodiments, the description of each embodiment has its own focus. For the part that is not described in detail in a certain embodiment, please refer to the detailed description of the data embedding request method above, which will not be repeated here.

[0104] It should be noted that, for the data embedding request method in the embodiment of the present application, those skilled in the art can understand that all or part of the process of implementing the data embedding request method in the embodiment of the present application can be completed by controlling the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, such as stored in the memory of the terminal, and executed by at least one processor in the terminal. During the execution process, it can include the process of the embodiment of the data embedding request method.

[0105] For the data point request device of the embodiment of the present application, its various functional modules can be integrated into a processing chip, or each module can exist physically separately, or two or more modules can be integrated into one module. The above-mentioned integrated modules can be implemented in the form of hardware or in the form of software functional modules. If the integrated modules are implemented in the form of software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium.

[0106] To this end, an embodiment of the present application provides a storage medium in which a plurality of instructions are stored, and the instructions can be loaded by a processor to execute the steps in any one of the data embedding request methods provided in the embodiment of the present application. The storage medium may be a disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), etc.

[0107] The data embedding request method, device, storage medium and electronic device provided by the present application are respectively introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the core idea of ​​the present application; at the same time, for technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A data point request method, characterized in that: include: When a tracking event is detected, the tracking event is stored in a local cache queue; Preprocessing the tracking events in the local cache queue, and sorting the processed tracking events according to a preset priority rule; When the preset conditions are met, the processed tracking events are packaged to generate tracking data packets; A burying point data request carrying the burying point data packet is sent to the server.

2. The data point request method according to claim 1, characterized in that: The pre-conditions include: The number of the burying point events in the local cache queue reaches a preset threshold, or the storage time of the burying point events in the local cache queue reaches a preset time threshold.

3. The data point request method according to claim 1, characterized in that: The pre-conditions include: The electronic device is detected to be idle and / or the network condition is good.

4. The data point request method according to claim 1, characterized in that: Preprocessing the tracking event in the local cache queue includes: The tracking events in the local cache queue are filtered to eliminate invalid or repeated tracking events.

5. The data point request method according to claim 4, characterized in that: The processed tracking event is packaged to generate a tracking data packet, including Performing statistics on the processed embedding events to generate statistical results; The statistical results and the buried point events are organized according to a preset data structure to form a buried point data packet.

6. The data burial point request method according to claim 5, characterized in that: The step of performing statistics on the processed buried events to generate statistical results includes: Obtain the event type, event parameters, event result and user profile of the event; Statistics are collected on the buried event type, the buried event parameters, the buried event results and the user portrait to generate statistical results.

7. The data point request method according to claim 1, characterized in that: After forming the burying point data packet and before sending the burying point data request carrying the burying point data packet to the server, the method further includes: The burying point data request carrying the burying point data packet is encrypted.

8. A data point request device, characterized in that: include: A monitoring unit, configured to store a buried event in a local cache queue when a buried event is detected; A processing unit, used to pre-process the tracking events in the local cache queue and sort the processed tracking events according to a preset priority rule; A packaging unit, used for packaging the processed tracking event to generate a tracking data packet when a preset condition is met; The sending unit is used to send a burying point data request carrying the burying point data packet to the server.

9. A storage medium, characterized in that: The storage medium stores multiple instructions, which are suitable for loading by a processor to execute the data burial point request method described in any one of claims 1-7.

10. An electronic device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the data burial point request method as described in any one of claims 1 to 7 when executing the computer program.

Images