Data processing method for push data recall, related equipment and storage medium

Abstract

This application discloses a data processing method, related equipment, and storage medium for push data recall. The method includes: responding to a data push test request for a specified push position; obtaining whiteboard data generated during the recall process of push data from the push database to the specified push position through a push service platform; obtaining a target push rule matching the specified push position from multiple push rules through a diagnostic platform; obtaining key data fields matching the target push rule from the whiteboard data; if the semantics of the key data fields do not match the push logic indicated by the target push rule, determining that the push data has not been pushed to the specified push position, and generating a recall diagnostic result for the push data according to the push logic indicated by the target push rule; and outputting the recall diagnostic result for the push data. The technical solution of this application can improve the efficiency of problem investigation and reduce the investigation cost when push data cannot be recalled.

Description

Technical Field

[0001] This application relates to the fields of computer and communication technology, and more specifically, to a data processing method for push data recall, a data processing apparatus for push data recall, an electronic device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Currently, the main methods for troubleshooting the issue of push data not being output in the corresponding push slot (i.e., push data not appearing or being unretrievable) include: first, debugging personnel manually obtain whiteboard data, and then analyze the whiteboard data based on their experience to determine the reason for the inability to retrieve push data. It is evident that the current troubleshooting process is almost entirely manual, resulting in low efficiency and high costs. Therefore, improving troubleshooting efficiency and reducing costs when push data cannot be retrieved is an urgent problem to be solved. Summary of the Invention

[0003] The embodiments of this application provide a data processing method, a data processing apparatus, an electronic device, a computer-readable storage medium, and a computer program product for recalling push data, which can improve the efficiency of problem investigation and reduce the cost of investigation when push data cannot be recalled.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a data processing method for push data recall is provided, including:

[0006] In response to a data push test request for a specified push position, the whiteboard data generated during the recall process of push data from the push database to the specified push position is obtained through the push service platform;

[0007] The diagnostic platform obtains the target push rule that matches the specified push position from multiple push rules; different push rules indicate different push logic;

[0008] Obtain the key data fields in the whiteboard data that match the target push rule;

[0009] If the semantics of the key data field does not match the push logic indicated by the target push rule, it is determined that the push data has not been pushed to the specified push position, and a recall diagnosis result indicating that the push data has not been pushed to the specified push position is generated according to the push logic indicated by the target push rule.

[0010] Output the recall diagnosis result of the pushed data; the recall diagnosis result is used to indicate the push logic that is not satisfied when the pushed data is not pushed to the specified push position.

[0011] According to one aspect of the embodiments of this application, a data processing apparatus for push data recall is provided, the apparatus comprising an acquisition unit, a processing unit, and an output unit, wherein:

[0012] The acquisition unit is used to respond to a data push test request for a specified push position and acquire whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform.

[0013] The processing unit is used to obtain a target push rule that matches the specified push position from multiple push rules through a diagnostic platform; different push rules indicate different push logic.

[0014] The processing unit is also used to obtain key data fields in the whiteboard data that match the target push rule;

[0015] The processing unit is further configured to determine that the push data has not been pushed to the specified push position if the semantics of the key data field does not match the push logic indicated by the target push rule, and generate a recall diagnosis result that the push data has not been pushed to the specified push position according to the push logic indicated by the target push rule.

[0016] The output unit is used to output the recall diagnosis result of the push data; the recall diagnosis result is used to indicate the push logic that is not satisfied when the push data is not pushed to the specified push position.

[0017] In one embodiment of this application, when the processing unit obtains a target push rule matching a specified push position from multiple push rules through a diagnostic platform, it may specifically be used to: obtain push range information of the specified push position through the diagnostic platform; wherein, the push range information includes at least one of the following: associated push data of the specified push position, push position information of the specified push position, application identifier information of the application to which the specified push position belongs, and environment identifier information of the environment initiating the data push request of the specified push position; obtain candidate push rules and adaptation range information of the candidate push rules from multiple push rules; if the adaptation range information of the candidate push rule matches the push range information, then the candidate push rule is determined as the target push rule.

[0018] In one embodiment of this application, multiple push rules are arranged in a preset order. When the processing unit obtains the target push rule that matches the specified push position from the multiple push rules through the diagnostic platform, it can specifically be used to: obtain the push range information of the specified push position through the diagnostic platform; select push rules in sequence according to the arrangement order of the multiple push rules, and match the adaptation range information of the selected push rules with the push range information until the adaptation range information of the selected push rules matches the push range information; and take the push rule whose adaptation range information matches the push range information as the target push rule.

[0019] In one embodiment of this application, the processing unit can be further configured to: concatenate key data fields with target push rules to obtain concatenated text; perform semantic correlation recognition processing on the concatenated text to obtain the semantic correlation between key data fields and target push rules; if the semantic correlation is less than or equal to a preset correlation threshold, determine that the semantics of key data fields does not match the push logic indicated by the target push rules.

[0020] In one embodiment of this application, multiple push rules are arranged in a preset order; the processing unit can be further configured to: if the semantics of a key data field matches the push logic indicated by the target push rule, then the push rule arranged after the target push rule and matching the specified push position is used as a new target push rule; obtain a new key data field in the whiteboard data that matches the new target push rule; when the semantics of the new data field does not match the push logic indicated by the new target push rule, determine that the push data has not been pushed to the specified push position, and generate a recall diagnosis result of the push data according to the push logic indicated by the new target push rule.

[0021] In one embodiment of this application, the acquisition unit can be further configured to: acquire object identification information of a specified object and push position information of a specified push position; search for historical data push requests initiated by a specified object through a specified push position from the object request database based on the object identification information and the push position identification information; wherein, the object request database is used to store historical data push requests initiated by multiple objects through multiple push positions; and generate a data push test request based on the found historical data push requests.

[0022] In one embodiment of this application, the acquisition unit can be further configured to: if no historical data push request initiated by a specified object through a specified push position is found in the object request database, then acquire a data push request that matches the push position identifier information from the online request database used to store historical data push requests initiated through multiple push positions; wherein the acquired data push request is used to acquire push data for the specified push position; and a data push test request is generated based on the acquired historical data push request.

[0023] In one embodiment of this application, when the acquisition unit generates a data push test request based on the found historical data push request, it can specifically be used to: convert the data format of the found historical data push request into a target data format to obtain a converted data push request; modify the parameter of the target field in the converted data push request to a preset debugging parameter to obtain a modified data push request; and generate a data push test request based on the modified data push request.

[0024] In one embodiment of this application, when the acquisition unit generates a data push test request based on the modified data push request, it can specifically be used to: acquire the push service type to which the specified push position belongs; acquire the request protocol corresponding to the push service type based on the pre-established correspondence between the push service type and the request protocol; and process the modified data push request based on the request protocol to generate a data push test request.

[0025] In one embodiment of this application, the data processing device for push data recall further includes a request initiation unit, which can be used to: obtain the push service type to which the specified push position belongs; obtain the request protocol corresponding to the push service type based on the pre-established correspondence between the push service type and the request protocol; obtain the packet transmission protocol corresponding to the request protocol based on the pre-established correspondence between the request protocol and the packet transmission protocol; and initiate a data push test request based on the packet transmission protocol.

[0026] In one embodiment of this application, when the acquisition unit responds to a data push test request for a specified push position and obtains the whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform, it can specifically be used to: send a data push test request to the push service platform so that the push service platform obtains the packet sending protocol corresponding to the specified push position, initiate a data push test request based on the packet sending protocol, and obtain the whiteboard data; and receive the whiteboard data returned by the push service platform.

[0027] In one embodiment of this application, when the output unit outputs the recall diagnosis result of the push data, it can be specifically used to: if the data push test request carries proxy processing information, send the recall diagnosis result of the push data to the proxy processing platform, so that the proxy processing platform can obtain the push request modification method that matches the recall diagnosis result of the push data, and modify the data push request initiated by the specified push position according to the push request modification method.

[0028] According to one aspect of the embodiments of this application, an electronic device is provided, including one or more processors; and a storage device for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to implement the data processing method for push data recall as described above.

[0029] According to one aspect of the embodiments of this application, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor of an electronic device, causes the electronic device to perform the data processing method for push data recall as described above.

[0030] According to one aspect of the embodiments of this application, this application provides a computer program product, including a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the data processing method for push data recall as described above.

[0031] In the technical solution provided by the embodiments of this application, by determining whether the semantics of the key data fields in the whiteboard data match the push logic indicated by the target push rule, a recall diagnosis result for the push data can be directly generated based on the push logic indicated by the target push rule when the semantics of the key data fields do not match the push logic indicated by the target push rule. Therefore, the embodiments of this application can autonomously identify the reasons why push data cannot be recalled, avoiding the need for manual analysis of whiteboard data to troubleshoot problems, greatly improving troubleshooting efficiency and reducing time and labor costs. Simultaneously, the embodiments of this application perform a certain screening on multiple push rules; only push rules that match a specified push position are used as target push rules for further judgment; this avoids the need to logically compare multiple fields in the whiteboard data with multiple push rules one by one. Therefore, the embodiments of this application can further improve troubleshooting efficiency by accurately selecting target push rules suitable for a specified push position.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0033] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0034] Figure 1 This is a schematic diagram of the structure of a data processing system for push data retrieval provided in an embodiment of this application;

[0035] Figure 2 This is a schematic flowchart illustrating a data processing method for push data recall, as shown in an exemplary embodiment of this application.

[0036] Figure 3 This is a schematic flowchart illustrating another data processing method for push data recall, as shown in an exemplary embodiment of this application.

[0037] Figure 4 This is a schematic diagram of the structure of a rule engine module provided in an embodiment of this application;

[0038] Figure 5A This is a schematic diagram of a push configuration interface shown in an exemplary embodiment of this application;

[0039] Figure 5B This is a schematic diagram illustrating a display interface for recall diagnostic results, as shown in an exemplary embodiment of this application.

[0040] Figure 6A This is a schematic diagram illustrating a display interface of the recall diagnosis results of multiple push data, as shown in an exemplary embodiment of this application;

[0041] Figure 6B This is an exemplary embodiment of the present application illustrating an interface diagram of the reasons for filtering in the coarse-sorting stage;

[0042] Figure 6C This is an exemplary embodiment of the present application illustrating an interface diagram of a filtering reason in the fine sorting stage;

[0043] Figure 7 This is a schematic flowchart illustrating another data processing method for push data recall, as shown in an exemplary embodiment of this application.

[0044] Figure 8 This is a schematic diagram of the structure of another data processing system for push data retrieval provided in an embodiment of this application;

[0045] Figure 9 This is a schematic flowchart illustrating another data processing method for push data recall, as shown in an exemplary embodiment of this application.

[0046] Figure 10 This is a schematic diagram illustrating a process for generating a data push test request, as shown in an exemplary embodiment of this application.

[0047] Figure 11This is a schematic diagram illustrating a process of obtaining data return packets, as shown in an exemplary embodiment of this application;

[0048] Figure 12 This is a structural block diagram of a data processing apparatus for push data recall, as illustrated in an exemplary embodiment of this application.

[0049] Figure 13 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

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

[0051] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0052] The flowcharts shown in the accompanying diagrams are merely illustrative and do not necessarily include all content and operations, nor do they necessarily have to be executed in the described order. For example, some operations may be broken down, while others may be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0053] It should also be noted that "multiple" as mentioned in this application refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0054] Websites, platforms, and applications (APPs) often incorporate push notifications into their core functionalities to recommend items to users. Therefore, certain interfaces within these applications may contain push notification slots for displaying this information.

[0055] The push data retrieval process refers to the journey of push data from the push database to the push position. The push database is the database used to store push data, and it can store multiple push data entries. During the retrieval process, push data needs to undergo filtering by various modules in the push system, including targeted matching, mixed / coarse ranking, fine ranking, and push data filling. If any module fails to match, the push data will be filtered out and ultimately cannot reach the push position for output. This situation is called push data not being output or push data being unretrievable.

[0056] In related technologies, the main method for troubleshooting the inability to recall push data is as follows: First, a person manually logs into the server storing the push request to retrieve the push request from the push position, and then manually modifies the push request to a debug state. Afterward, the debugger resends the modified push request, causing the corresponding server to respond and obtain a push response packet containing whiteboard data. The whiteboard data includes the processing data of the push data during the recall process. Specifically, the whiteboard data includes detailed processing data from when the push data comes out of the push database, processed by modules in the push system such as targeted matching, mixed / coarse ranking, fine ranking, and push data filling. Finally, the debugger analyzes the whiteboard data to troubleshoot the reason for the inability to recall push data. This approach is almost entirely manual, resulting in low efficiency and high cost.

[0057] Based on this, this application provides a data processing scheme for push data recall. This scheme pre-compiles multiple push rules; then, it responds to data push test requests for a specified push position and obtains the whiteboard data corresponding to the push data through the push service platform. Simultaneously, a diagnostic platform can obtain a target push rule matching the specified push position from the aforementioned multiple push rules. This allows for the generation of a recall diagnostic result indicating that the push data was not pushed to the specified push position when the key data fields in the whiteboard data do not match the push logic indicated by the target push rule.

[0058] Among them, a data push test request refers to a data push request that has been modified to debug mode, i.e., the data push test request contains `debug=true`. Additionally, there may be restrictions on which push data can be displayed for certain push positions, or that push positions in certain applications do not require targeted matching, causing some push rules to be unsuitable for specific push positions. Therefore, it is necessary to obtain the target push rule that matches the specified push position. The key data fields in the whiteboard data refer to the fields in the whiteboard data that match the target push rule.

[0059] In addition, the push service platform is used to recall push data, that is, to determine the push data to be finally output in the push position from the push data in the push database. Specifically, the push service platform is equivalent to the aforementioned push system, including modules such as targeted matching, mixed / coarse ranking, fine ranking, and push data filling. The push service platform can process and filter push data through these modules, and record the processing data of each module to form blank data.

[0060] Furthermore, the diagnostic platform can store multiple push rules and can be further used to analyze the recall diagnostic results of push data through multiple push rules. Different push rules indicate different push logic. Each push rule can be derived from the processing logic of various modules such as different targeting matching, mixed / coarse ranking, fine ranking, and push data filling, or it can be summarized from the debugging personnel's experience in analyzing whiteboard data; there are no limitations on this. For example, during targeting matching, push data that does not match the corresponding targeting will be filtered out, resulting in the inability to recall the push data. Therefore, the push logic indicated by the push rule could be: push data matches targeting A, and the push data is added to the push data queue of the next processing module.

[0061] Meanwhile, the recall diagnostic results are used to indicate push logic issues arising from push data not being pushed to the specified push position. Whiteboard data includes processing data of push data during the recall process; and key fields in the whiteboard data that match the target push rule refer to fields in the whiteboard data with high text similarity to the target push rule. Specifically, whiteboard data includes processing data from each module during the recall process, essentially recording the detailed process of how push data is processed by each module. Specifically, whiteboard data can include information such as which targeting mismatches, which targeting matches, which push data queues the push data entered, which push data queues filtered it, and the reasons for filtering, etc.

[0062] Therefore, if the semantics of the key data fields do not match the push logic of the target push rule, it means that the push data is filtered in the processing module corresponding to the push logic indicated by the target push rule, resulting in the push data not being pushed to the push position; then, the recall diagnosis result of the push data can be directly analyzed according to the push logic indicated by the target push rule.

[0063] It's clear that this solution, by determining whether key data fields match the push logic indicated by the target push rule, can directly generate recall diagnostic results for push data based on the push logic indicated by the target push rule when the semantics of key data fields do not match. Therefore, this solution effectively avoids scenarios requiring manual analysis of whiteboard data to troubleshoot problems, improving troubleshooting efficiency and reducing costs. Furthermore, this solution filters multiple push rules, only those matching a specified push position are used as target push rules for further judgment; this avoids the need to logically compare multiple fields in the whiteboard data with multiple push rules one by one. Therefore, this solution further improves troubleshooting efficiency by accurately selecting target push rules suitable for a specified push position.

[0064] Based on the above-mentioned data processing scheme for push data retrieval, this application provides a data processing system for push data retrieval, which can be found in [reference]. Figure 1 , Figure 1 The data processing system for push data retrieval shown may include multiple terminal devices 101 and multiple servers 102. A communication connection is established between any terminal device and any server. For example, terminal device 101 may include any one or more of smartphones, tablets, laptops, desktop computers, smart in-vehicle devices, and smart wearable devices. Terminal device 101 may run multimedia playback clients, social clients, browser clients, information stream clients, educational clients, etc. Server 102 may be a server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. Any terminal device 101 and any server 102 may communicate directly or indirectly via wired or wireless communication; this application does not impose any limitations on this.

[0065] In some embodiments, the data processing method for push data recall described above may be solely provided by Figure 1The data processing system for push data recall, as shown, is executed by server 102. The specific execution process is as follows: Server 102 can respond to a data push test request for a specified push position and obtain whiteboard data generated during the recall process from the push database to the specified push position through the push service platform. Then, server 102 can obtain the target push rule matching the specified push position from multiple push rules through a diagnostic platform. Afterwards, server 102 can obtain the key data fields matching the target push rule from the whiteboard data. If server 102 determines that the semantics of the key data fields do not match the push logic indicated by the target push rule, server 102 can determine that the push data was not pushed to the specified push position and generate a recall diagnostic result for the push data not being pushed to the specified push position based on the push logic indicated by the target push rule. Finally, server 102 can output the recall diagnostic result of the push data.

[0066] Optionally, server 102 can also modify the data push request initiated by the specified push position based on the recall and diagnostic results of the push data, so that the modified data push request can obtain the corresponding push data for the specified push position. Optionally, the diagnostic platform and push service platform can run on the terminal device or on the server, without limitation. Optionally, the above-mentioned data processing method for push data recall can also be performed solely by... Figure 1 The terminal device 101 in the data processing system for push data recall shown executes the process. The specific execution process can be found in the specific execution process of the server 102, and will not be described again here.

[0067] In other embodiments, the data processing method for push data retrieval described above can run on a data processing system for push data retrieval, which may include terminal devices and servers. Specifically, the data processing method for push data retrieval may be... Figure 1The data processing system for push data retrieval shown is jointly completed by terminal device 101 and server 102. The specific execution process is as follows: Terminal device 101 sends a data push test request to server 102; then, server 102 responds to the data push test request for a specified push position, obtaining the whiteboard data generated during the retrieval process from the push database to the specified push position through the push service platform. Next, server 102 can obtain the target push rule matching the specified push position from multiple push rules through a diagnostic platform. Then, server 102 can obtain the key data fields matching the target push rule from the whiteboard data. If server 102 determines that the semantics of the key data fields do not match the push logic indicated by the target push rule, server 102 can determine that the push data was not pushed to the specified push position and generate a retrieval diagnostic result indicating that the push data was not pushed to the specified push position based on the push logic indicated by the target push rule. Finally, server 102 can send the retrieval diagnostic result of the push data to terminal device 101, and terminal device 101 outputs the retrieval diagnostic result of the push data.

[0068] Optionally, the terminal device 101 can also modify the data push request initiated by the specified push position based on the recall and diagnostic results of the push data, so that the modified data push request can obtain the corresponding push data for the specified push position. Optionally, the diagnostic platform and the push service platform can run on the terminal device or on the server, without limitation.

[0069] It should be noted that the embodiments of this application can process data recalled from various push data, and can be applied to various scenarios, including but not limited to cloud technology, AI (Artificial Intelligence), smart home, assisted driving and other scenarios. It can also be used to investigate the reasons why push data cannot be recalled in various applications such as video applications, social applications, shopping applications, etc., and there is no limitation thereto.

[0070] Specifically, the technical solutions of this application embodiment can be applied to smart home scenarios. For example, the terminal device can be set as a smart refrigerator in a smart home scenario, and the server can be a data processing server that provides push data recall services for the smart refrigerator. The push data can be recipes, beverages, supermarket discount information, etc. The display screen of the smart refrigerator can include multiple push positions. If the smart refrigerator detects that a certain push position does not display push data, the smart refrigerator can use that push position as the designated push position and generate a data push test request for the designated push position. Then, the smart refrigerator sends the data push test request to the server, and the server responds to the data push test request for the designated push position by obtaining the whiteboard data generated during the recall process of push data from the push database to the designated push position through the push service platform. Then, the server can obtain the target push rule that matches the designated push position from multiple push rules through the diagnostic platform; then, the server can obtain the data key field that matches the target push rule in the whiteboard data. If the server detects that the semantics of the data key field does not match the push logic indicated by the target push rule, the server can determine that the push data has not been pushed to the designated push position and generate a recall diagnostic result of push data not being pushed to the designated push position according to the push logic indicated by the target push rule. Finally, the server can output the recall diagnostic results of the pushed data.

[0071] For example, applying the technical solution of this application embodiment to troubleshoot the reasons why push data cannot be recalled in a video application, the terminal device can run a diagnostic platform for push data of the video application. The diagnostic platform can display multiple recommendation slots in the video application, as well as one or more historical data push requests initiated by each recommendation slot. Then, the terminal device can respond to the developer's selection operation of multiple recommendation slots in the diagnostic platform to obtain the specified recommendation slot; and the terminal device can also respond to the developer's selection operation of one or more historical data push requests initiated by the specified recommendation slot in the diagnostic platform to obtain the target data push request. Afterwards, the terminal device can send the specified push slot and the target data push request to the server, so that the server can generate a data push test request for the specified push slot based on the target data push request.

[0072] Afterwards, the server can respond to data push test requests for a specified push position and obtain whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform. Then, the server can obtain the target push rule matching the specified push position from multiple push rules through the diagnostic platform; subsequently, the server can obtain the data key fields matching the target push rule from the whiteboard data. If the server detects that the semantics of the data key fields do not match the push logic indicated by the target push rule, the server can determine that the push data was not pushed to the specified push position and generate a recall diagnostic result for the push data not being pushed to the specified push position based on the push logic indicated by the target push rule. Finally, the server can send the recall diagnostic result of the push data to the terminal device, so that the terminal device can display the recall diagnostic result of the push data through the diagnostic platform.

[0073] It should be noted that in the specific implementation of this application, if the recommended data, whiteboard data, and other related data or information involve the object, when the embodiments of this application are applied to specific products or technologies, permission or consent from the object is required, and the collection, use, and processing of related data or information must comply with the relevant laws, regulations, and standards of the relevant countries and regions.

[0074] The following details the various implementation details of the technical solutions in the embodiments of this application:

[0075] like Figure 2 As shown, Figure 2 This is a flowchart illustrating a data processing method for push data retrieval, as shown in one embodiment of this application. This method can be applied to... Figure 1 The data processing system for push data retrieval shown can be executed by a terminal device or a server, or by both. In this embodiment, the method is described using the server as an example. The data processing method for push data retrieval may include steps S201 to S205, which are detailed below:

[0076] S201. Respond to the data push test request for the specified push position, and obtain the whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform.

[0077] In this embodiment, a push position refers to the location in the application interface of the application software where push data is displayed. A specified push position refers to a specific push position in the application interface of the application software.

[0078] Furthermore, a data push test request refers to a data push request that has been modified to a debug state, meaning it contains `debug=true`. Specifically, a data push test request can be generated by modifying a historical data push request initiated from a specified recommendation position. Additionally, the number of pushed data items can be one or more. Correspondingly, there is a correspondence between pushed data and whiteboard data; therefore, the number of whiteboard data items can also be one or more.

[0079] Additionally, the push service platform is used for push data recall, that is, to determine the final push data to be output from the push database. Whiteboard data includes the processing data of push data during the recall process.

[0080] In one embodiment, the specified push position can be determined by: the server displaying multiple push positions; responding to the selection operation of multiple push positions, and obtaining the selected specified push position.

[0081] Optionally, the method for determining the designated push position can also be: if the server detects that no push data is displayed in any push position in the application interface, then that push position is taken as the designated push position.

[0082] Optionally, personalized recommendations may be made based on different users. Therefore, if different users log into the application, the same recommendation slot will display different push data, leading to different reasons why push data cannot be retrieved depending on the user. Therefore, another way to determine the specified push slot is as follows: the server can display a push configuration interface including user configuration options; then, the server responds to editing operations on the user configuration options to determine the configured user; subsequently, the server can obtain multiple recommendation slots viewed by the configured user during application usage and display these slots; finally, the server can respond to selection operations on the obtained recommendation slots to retrieve the selected recommendation slot. Optionally, other methods can also be used to determine the specified push slot, and this is not limited.

[0083] In one embodiment, the push service platform may be deployed on other servers. The whiteboard data can then be obtained as follows: the server sends a data push test request to the push service platform, which responds to the request. During the process of calling various modules to process the pushed data, the push service platform obtains the processing data from each module, including processing process data and processing result data. The push service platform then sends the obtained processing data to the server as whiteboard data.

[0084] Specifically, since the push service platform includes modules such as targeted matching, mixed / coarse ranking, fine ranking, and push data population, and whiteboard data includes the processing data of push data during the recall process, whiteboard data can specifically include information such as which targets the push data did not match, which targets matched, which push data queues it entered, which push data queues it was filtered by, and the reasons for the filtering, etc.

[0085] In one embodiment, the server itself may run a push service platform. The whiteboard data can be obtained as follows: the server responds to a data push test request for a specified push position through the push service platform, and obtains a data response packet for the data push test request; the data response packet contains the whiteboard data corresponding to the pushed data. After receiving the data push test request, the push service platform processes the pushed data according to the order of the various modules, and records the processing information of each module during the processing to generate a data response packet containing the whiteboard data.

[0086] It should be noted that since some push data may be filtered in one of the modules such as targeted matching, mixed / coarse ranking, fine ranking, and push data population, the processed data obtained by the modules listed after the aforementioned module in the push service platform will not be obtained. Therefore, the blank data of these push data can only include the processed data of the aforementioned module, as well as the processed data of the modules listed before the aforementioned module in the push service platform.

[0087] S202. Obtain the target push rule that matches the specified push position from multiple push rules through the diagnostic platform.

[0088] In the embodiments of this application, different push rules indicate different push logics. Each push rule can be obtained by organizing and analyzing the processing logic of various modules such as targeted matching, mixed / coarse ranking, fine ranking, and push data filling, or it can be obtained by summarizing the debugging experience of whiteboard data. There is no limitation on this.

[0089] Meanwhile, the diagnostic platform can store multiple push rules, and can also be further used to analyze the push data and retrieve diagnostic results through multiple push rules. The diagnostic platform can be deployed on the server in the embodiments of this application, or it can be deployed on other servers; there is no limitation on this.

[0090] Furthermore, the specific method for obtaining the target push rule matching a specified push position from multiple push rules through the diagnostic platform can be as follows: obtain the push range information of the specified push position through the diagnostic platform; obtain candidate push rules and their adaptation range information from multiple push rules; if the adaptation range information of the candidate push rule matches the push range information, then the candidate push rule is determined as the target push rule. It should be noted that the adaptation range information of different push rules is not entirely the same.

[0091] The compatibility information of candidate push rules includes the scenarios or conditions under which the candidate push rules can be used. Each push rule carries corresponding compatibility information. Optionally, some push rules may have compatibility information applicable to all scenarios and conditions; in this case, such push rules will definitely match the specified push position. Optionally, the push range information for the specified push position may be carried in the data push test request after the specified push position initiates the data push test request, so the diagnostic platform can directly obtain the push range information for the specified push position.

[0092] Alternatively, the diagnostic platform can obtain candidate push rules from multiple push rules in a specific way, such as randomly selecting one rule as a candidate. Optionally, the multiple push rules can be arranged in a certain order, in which case the diagnostic platform can select a push rule according to the order of the multiple rules and use the selected rule as a candidate. Other methods can also be used to obtain candidate push rules from multiple push rules; there are no limitations on this.

[0093] Meanwhile, the push range information may include at least one of the following: the associated push data of the specified push position, the push position information of the specified push position, the application identifier information of the application to which the specified push position belongs, and the environment identifier information of the environment in which the specified push position initiates the data push request.

[0094] In one embodiment, the associated push data for a specified push position may include one or more of the following: pre-defined push data that can be displayed by the specified push position, pre-defined push data that cannot be displayed by the specified push position, push data that can be displayed by the specified push position within a first preset time period, push data that cannot be displayed by the specified push position within a second preset time period, and so on. The first and second preset times can be set according to factors such as the target audience's needs and the price of the push data delivery, and are not limited thereto.

[0095] Since there may be situations where a specific push position can only display certain push data, and the adaptation range information of some push rules can include the push data to which the corresponding push rule applies, if the push data associated with the specified push position does not belong to the push data to which the candidate push rule applies, it can be determined that the adaptation range information of the candidate push rule does not match the push range information; if the push data associated with the specified push position belongs to the push data to which the candidate push rule applies, it can be determined that the adaptation range information of the candidate push rule matches the push range information.

[0096] In one embodiment, the push information of the specified push position may include one or more of the following: push position identifier information of the specified push position, interface identifier information of the display interface containing the specified push position in the application software, position identifier information of the specified push position in the corresponding interface, and proxy processing information carried in the data push request initiated by the specified push position, etc., without limitation.

[0097] Since different push logic may be designed for push positions at different locations, the adaptation range information of some push rules may include the location information of the push positions to which the corresponding push rule applies. Therefore, if the location indicated by the push position information of the specified push position is different from the location information to which the candidate push rule applies, it can be determined that the adaptation range information of the candidate push rule does not match the push range information; if the location indicated by the push position information of the specified push position is the same as the location information to which the candidate push rule applies, it can be determined that the adaptation range information of the candidate push rule matches the push range information.

[0098] In one embodiment, the application identifier information of the application to which the push position belongs may include one or more of the following: a unique identifier indicating the application to which the push position belongs, and the application type of the application to which the push position belongs. There is no limitation on this.

[0099] Because different push logic may be designed for different application types or different applications, the scope of application for certain push rules may include the applications or application types to which the corresponding push rule applies. Therefore, if the application identifier information of the specified push bit indicates a different application or application type than the application or application type to which the candidate push rule applies, it can be determined that the scope of application for the candidate push rule does not match the scope of application. Conversely, if the application identifier information of the specified push bit indicates the same application or application type as the application or application type to which the candidate push rule applies, it can be determined that the scope of application for the candidate push rule matches the scope of application.

[0100] In one embodiment, the environment identification information is used to indicate the initiating environment of the data push request initiated by the specified push bit.

[0101] Application software development and iterative updates heavily rely on applications built in multiple environments, such as test environments (for testing application functionality), production environments (for applications actually used by users), and sandbox environments (environments highly similar to production environments). The same push notification location may have different push logic in different environments. Therefore, the compatibility information of certain push rules can include the environments to which the corresponding push rule applies. Thus, if the initiating environment indicated by the environment identifier is different from the environment to which the candidate push rule applies, it can be determined that the compatibility information of the candidate push rule does not match the push range information; conversely, if the initiating environment indicated by the environment identifier is the same as the environment to which the candidate push rule applies, it can be determined that the compatibility information of the candidate push rule matches the push range information.

[0102] In one possible implementation, since the aforementioned push rules can be obtained by analyzing and organizing the processing logic of various modules such as targeted matching, mixed / coarse ranking, fine ranking, and push data filling, the applicability information of certain push rules can further include one or more of the following: the applicable targeting, the applicable coarse ranking method, and the applicable filling method. Since the whiteboard data includes the processing data of each module, the push scope information can also further include the whiteboard data.

[0103] For example, if the targeting contained in the whiteboard data is different from the targeting applicable to the candidate push rule, it can be determined that the adaptation range information of the candidate push rule does not match the push range information; if the targeting contained in the whiteboard data is the same as the targeting applicable to the candidate push rule, it can be determined that the adaptation range information of the candidate push rule matches the push range information.

[0104] S203. Obtain the key data fields in the whiteboard data that match the target push rule.

[0105] In this embodiment, since the whiteboard data includes processing data from various modules during the recall process, and the processing data mainly consists of fields, the specific method for obtaining the key data fields in the whiteboard data that match the target push rule can be: obtaining the text similarity between each field in the whiteboard data and the target push rule, and determining the fields with text similarity greater than a preset similarity threshold as key data fields.

[0106] The preset similarity threshold can be set manually or by the server or terminal device in the data processing system for push data retrieval mentioned above; there is no limitation on this. Optionally, key data fields can also be obtained through other methods; there is no limitation on this either. In addition, since a field is a text and the target push rule is also a text, and the method of obtaining the text similarity between the two texts is a technical means commonly used by those skilled in the art, it will not be described in detail here.

[0107] S204. If the semantics of the key data fields do not match the push logic indicated by the target push rule, it is determined that the push data has not been pushed to the specified push position, and a recall diagnosis result for the push data not being pushed to the specified push position is generated according to the push logic indicated by the target push rule.

[0108] In this embodiment, the recall diagnostic result is used to indicate the push logic that was not met because the pushed data was not pushed to the specified push position; essentially, it is used to indicate the reason why the pushed data cannot be recalled. Specifically, the recall diagnostic result can be text describing the push logic that was not met by the pushed data. Optionally, a correspondence between result identifiers and reasons for non-recall can be pre-established, in which case the recall diagnostic result can be the result identifier corresponding to the reason for non-recall. The result identifier can be characters, numbers, images, or other unique identifiers that can identify the reason for non-recall; there is no limitation on this.

[0109] Since the semantics of the key data fields do not match the push logic indicated by the target push rule, it means that the pushed data was filtered out in a processing logic similar to or the same as the push logic indicated by the target push rule. Therefore, the push logic indicated by the target push rule is the push logic that was not satisfied when the pushed data was not pushed to the specified push position. Thus, a specific way to generate the recall diagnostic results for the pushed data could be to directly analyze and process the push logic indicated by the target push rule to generate the recall diagnostic results for the pushed data.

[0110] In one embodiment, whether the semantics of the key data field matches the push logic indicated by the target push rule can refer to whether the semantics of the key data field are similar to or the same as the semantics of the target push rule.

[0111] Optionally, the specific method for determining whether the semantics of the key data fields match the push logic indicated by the target push rule can be: concatenating the key data fields with the target push rule to obtain concatenated text; performing semantic correlation recognition processing on the concatenated text to obtain the semantic correlation between the key data fields and the target push rule; if the semantic correlation is less than or equal to a preset correlation threshold, then it is determined that the semantics of the key data fields do not match the push logic indicated by the target push rule.

[0112] Optionally, if the semantic relevance is greater than a preset relevance threshold, then the semantics of the key data fields are determined to match the push logic indicated by the target push rule.

[0113] The preset relevance threshold can be set manually or by the server or terminal device in the aforementioned push data retrieval data processing system; there is no limitation on this. Furthermore, semantic relevance recognition can be performed using a trained relevance recognition model. Specifically, the trained relevance recognition model can be obtained by training pre-trained language models such as BERT (Bidirectional Encoder Representations from Transformer), XLNet (autoregressive and autoencoder model), and LayoutLM (Pre-training of Text and Layout for Document Image Understanding). Since the specific methods for developing the relevance recognition model are techniques commonly used by those skilled in the art, they will not be elaborated upon here.

[0114] For example, the target push rule could be to determine whether the delivery time of push data R is between 10:00 and 11:00. After obtaining the key data field Q in the whiteboard data of push data R that matches the target push rule, if the semantics of key data field Q indicate that the delivery time of push data R is 12:10, then it means that the semantics of key data field Q do not match the push logic indicated by the target push rule for a delivery time between 10:00 and 11:00. Therefore, based on the push logic indicated by the target push rule, it can be diagnosed that the push logic that push data R does not meet is that the delivery time is between 10:00 and 11:00, thus generating a recall diagnosis result for push data R. Optionally, it is also possible to analyze the inverse logic of the push logic indicated by the target push rule to determine that the reason why push data R cannot be recalled is that the delivery time is not between 10:00 and 11:00, thus generating a recall diagnosis result for push data R.

[0115] Furthermore, since the key data fields in the whiteboard data specifically describe where the push data is filtered during the recall process, the specific way to generate the recall diagnosis results of the push data according to the target push rules can also be: generate the recall diagnosis results of the push data based on the semantics of the key data fields and the push logic indicated by the target push rules.

[0116] S205, Output the recall diagnosis results of the pushed data.

[0117] In this embodiment, the specific method for outputting the recall diagnosis results of the push data can be: displaying the recall diagnosis results of the push data. Optionally, the recall diagnosis results of the push data can also be output via SMS, email, or other means. Optionally, the recall diagnosis results of the push data can also be output via other means, which are not limited.

[0118] Optionally, based on the experience of debugging personnel in manually troubleshooting issues that cannot recall push data, a correspondence between recall diagnosis results and solutions can be established. Then, in addition to outputting the recall diagnosis results of push data, the server can also look up the solutions corresponding to the recall diagnosis results. Furthermore, when outputting the recall diagnosis results of push data, the corresponding solutions can also be output together.

[0119] Optionally, the solution may include modifying the push request method. After the server finds the push request modification method corresponding to the recall diagnostic result, it can modify the data push request initiated by the specified push position so that the modified data push request can obtain the corresponding push data for the specified push position.

[0120] In practical applications, analyzing whiteboard data has a high barrier to entry. On the one hand, there is a lot of data to process, with an average of about 120,000 rows of data on a whiteboard, which debuggers need to view and analyze one by one. On the other hand, most of the whiteboard data is highly specialized, and only personnel with specific development and debugging experience can analyze it.

[0121] In this embodiment, by determining whether the semantics of key data fields in the whiteboard data match the push logic indicated by the target push rule, a recall diagnosis result for the push data can be directly generated based on the push logic indicated by the target push rule when the semantics of the key data fields do not match the push logic indicated by the target push rule. Therefore, this embodiment can autonomously identify the reasons for the inability to recall push data, avoiding the need for manual analysis of whiteboard data to troubleshoot problems, greatly improving troubleshooting efficiency and reducing time and labor costs. Simultaneously, this embodiment filters multiple push rules, only those matching a specified push position are used as target push rules for further judgment; this avoids the need to logically compare multiple fields in the whiteboard data with multiple push rules one by one. Therefore, this embodiment further improves troubleshooting efficiency by accurately selecting target push rules suitable for a specified push position.

[0122] Furthermore, since application software version update testing relies on the recall of push data, only when push data can be recalled can the interaction logic of the application software running on the terminal device regarding push data be verified. The embodiments of this application can significantly improve the efficiency of troubleshooting issues related to the inability to recall push data, thereby reducing the likelihood of version update testing being blocked due to the inability to recall push data, and thus helping to reduce the risk of application software requirements being delayed due to version testing blockage.

[0123] In one embodiment of this application, another data processing method for push data recall is provided, which can be applied to... Figure 1 The data processing system for push data retrieval shown can be executed by a terminal device or a server, or by both. In this embodiment, the method is described using the server as an example. Figure 3 The diagram illustrates a flowchart of another data processing method for push data retrieval. This data processing method for push data retrieval... Figure 2 The method shown is an extension of the one presented.

[0124] The details of S301 to S307 are as follows:

[0125] S301. Respond to the data push test request for the specified push position, and obtain the whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform.

[0126] In this embodiment, the specific implementation of step S301 can be found in the specific implementation of step S201 in the above embodiments, and will not be repeated here.

[0127] S302. Obtain the push range information of the specified push position through the diagnostic platform.

[0128] In this embodiment of the application, referring to the description of the push range information in step S202, the push range information may include at least one of the following: associated push data of a specified push position, push position information of the specified push position, application identifier information of the application to which the specified push position belongs, and environment identifier information of the environment initiating the data push request of the specified push position. Optionally, the push range information may further include whiteboard data. Specific descriptions of the associated push data, push position information, application identifier information, and environment identifier information can be found in the specific implementation of step S202, and will not be repeated here.

[0129] S303. Select push rules in sequence according to the order of multiple push rules, and match the adaptation range information of the selected push rules with the push range information until the adaptation range information of the selected push rules matches the push range information.

[0130] In this embodiment, multiple push rules can be arranged in a preset order. Since the matching results of the push logic indicated by some push rules with the corresponding fields in the whiteboard data may affect the matching results of the push logic indicated by other push rules with the corresponding fields in the whiteboard data; the matching results are used to indicate whether the semantics of the fields in the whiteboard data match the push logic indicated by the corresponding push rule.

[0131] Meanwhile, since the push data retrieval process filters push data in a coarse-grained and fine-grained order, if push data is filtered during coarse-grained ranking, then there is no need to match push rules for fine-grained ranking. Therefore, push rules for coarse-grained ranking can be placed before push rules for fine-grained ranking. Thus, a preset order can be determined based on the debugging experience of the debugging personnel, and multiple push rules can be arranged according to the preset order.

[0132] Specifically, the first push rule among multiple push rules can be used as a candidate push rule, and its adaptation range information can be used as the candidate push rule. If the adaptation range information of the candidate push rule matches the push range information, the candidate push rule is determined as the target push rule. If the adaptation range information of the candidate push rule does not match the push range information, the next push rule of the candidate push rule is used as a new candidate push rule, and its adaptation range information is used as the adaptation range information of the new candidate push rule, until the adaptation range information of the new candidate push rule matches the push range information, at which point the new candidate push rule is used as the target push rule.

[0133] S304. The push rule that matches the adaptation range information with the push range information shall be used as the target push rule.

[0134] In this embodiment, the specific implementation of step S304 can be found in the specific implementation of step S202 in the above embodiment, and will not be repeated here.

[0135] S305. Obtain the key data fields in the whiteboard data that match the target push rule.

[0136] In this embodiment, the specific implementation of step S305 can be found in the specific implementation of step S203 in the above embodiment, and will not be repeated here.

[0137] S306. If the semantics of the key data fields do not match the push logic indicated by the target push rule, it is determined that the push data has not been pushed to the specified push position, and a recall diagnosis result for the push data not being pushed to the specified push position is generated according to the push logic indicated by the target push rule.

[0138] In this embodiment, the specific implementation of step S306 can be found in the specific implementation of step S204 in the above embodiment, and will not be repeated here.

[0139] S307, Output the recall diagnosis results of the pushed data.

[0140] In this embodiment, the specific implementation of step S307 can be found in the specific implementation of step S205 in the above embodiment, and will not be repeated here.

[0141] Optionally, if the data push test request carries proxy processing information, the recall diagnosis result of the push data will be sent to the proxy processing platform so that the proxy processing platform can obtain the push request modification method that matches the recall diagnosis result of the push data, and modify the data push request initiated by the specified push position according to the push request modification method.

[0142] Specifically, the modified data push request from the proxy processing platform can enable the display of push data in a specified push position. For example, if the recall diagnosis result of the push data indicates that the reason for the inability to recall the push data is that the targeting Y is being filtered, then the push request modification method obtained by the proxy processing platform that matches the recall diagnosis result of the push data can be modified to allow the push data to skip targeting Y.

[0143] Therefore, it is evident that by using a proxy processing platform, the workload of debugging personnel can be further reduced, and the process of troubleshooting the reasons for the inability to recall push data and resolving the problem of inability to recall push data can be fully automated, which is conducive to further reducing time, labor and other costs.

[0144] In one possible implementation, if the semantics of a key data field matches the push logic indicated by the target push rule, then the push rule that follows the target push rule and matches the specified push position can be used as the new target push rule. Then, a new key data field matching the new target push rule is obtained from the whiteboard data. Finally, if the semantics of the new key data field does not match the push logic indicated by the new target push rule, it is determined that the push data was not pushed to the specified push position, and a recall diagnostic result for the push data is generated based on the push logic indicated by the new target push rule.

[0145] Optionally, since step S302 mentions that the matching result of the push logic indicated by some push rules with the whiteboard data may affect the matching result of the push logic indicated by other push rules with the corresponding fields in the whiteboard data, the specific way to determine whether the new data key fields conform to the push logic indicated by the new target push rule can also be: based on the matching result between the target push rule before the new target push rule and the corresponding data key fields in the whiteboard data, determine whether the new data key fields match the push logic indicated by the new target push rule.

[0146] For example, multiple push rules may include proxy processing rules and stability rules. The push logic indicated by the proxy processing rule is: detecting whether a data push test request initiated by a specified push position carries proxy processing information, and the scope of application information for the proxy processing rule is not limited to the applicable scenarios and conditions. The push logic indicated by the stability rule is: detecting whether the environment initiating the data push test request is available, and the scope of application information for the stability rule is a preset environment, where the preset environment can be one or more of the test environment, online environment, and sandbox environment mentioned in step S202.

[0147] Because if a data push test request initiated by a specified push position carries proxy processing information, the proxy processing platform may edit the data push test request. This means the final initiation environment of the data push test request should be the proxy processing platform's initiation environment, whereas the previously obtained initiation environment was the one initiated by the specified push position. Therefore, if the proxy processing rules detect that a data push test request initiated by a specified push position carries proxy processing information, the server may need to re-obtain the proxy processing platform's initiation environment to assess subsequent stability rules.

[0148] For specific implementation details, please refer to the appendix. Figure 4 This illustrates a schematic diagram of the architecture of a rules engine module. For example... Figure 4 As shown, the rule engine module includes an ordered rule pool 401 and a scheduler 402. The ordered rule pool 401 contains multiple push rules, such as... Figure 4 As shown, the ordered rule pool 401 includes multiple push rules, such as proxy processing rules, stability rules, push rules for push data A, and push rules for target M. The push logic for the push rule for push data A may include whether the delivery time of push data A is within the specified delivery time of push data A, and whether push data A is valid. The push logic for the push rule for target M may include whether the push data is filtered when targeted by M.

[0149] like Figure 4As shown in the push rules for push data A and push rules for target M, before writing each push rule into the ordered rule pool 401, it is necessary to pre-register the priority of each push rule in order to determine the order of each push rule in the ordered rule pool 401. It should be noted that the priority of each push rule can be registered and set by the debugging personnel based on debugging experience, or it can be set by the terminal device or server in the data processing system for push data retrieval mentioned above; there is no limitation on this.

[0150] After the server obtains the whiteboard data generated during the recall process of push data B from the push database to the specified push position, the server can obtain candidate push rules from the ordered rule pool 401 through scheduler 402, such as... Figure 4 As shown, the candidate push rules obtained for the first time are proxy processing rules.

[0151] Then, scheduler 402 will further execute step 403 to determine whether the adaptation range information of the candidate push rule matches the push range information of the specified push position. If they do not match, scheduler 402 will obtain the next push rule of the candidate push rule from the ordered rule pool 401 as a new candidate push rule; if they match, scheduler 402 will input the candidate push rule as the target push rule and the whiteboard data together into the rule matching processing unit 404. The rule matching processing unit 404 will determine the data key fields in the whiteboard data that match the target push rule, and compare the push logic indicated by the target push rule with the semantics of the data key fields to obtain the matching result; wherein, the matching result is used to indicate whether the semantics of the data key fields match the push logic indicated by the target push rule.

[0152] Next, scheduler 402 executes step 405, which determines whether to end the scheduling based on the matching result output by rule matching processing unit 404. If the matching result indicates that the semantics of the key data field matches the push logic indicated by the candidate push rule as the target push rule, then the scheduling is not over. Scheduler 402 will then retrieve the next push rule of the candidate push rule from the ordered rule pool 401 as a new candidate push rule and execute all the above steps. If the matching result indicates that the semantics of the key data field does not match the push logic indicated by the candidate push rule as the target push rule, then the scheduling is over. Scheduler 402 can then execute step 406, which generates a recall diagnostic result based on the push logic indicated by the candidate push rule.

[0153] For practical applications, please refer to the appendix. Figure 5AThe diagram illustrates a push configuration interface. The push configuration interface 501 includes an object ID input box 502 (i.e., object configuration options). The debugger enters the object ID 111225632 in the object ID input box 502; then, a request selection interface 503 is displayed. This interface contains historical data push requests initiated by multiple recommendation slots viewed by object 111225632. Recommendation slot 8040486525039375 is a recommendation slot in function 001 of application A, and object 111225632 viewed recommendation slot 8040486525039375 on 2023-01-10-17:48:30. Similarly, other recommendation slots 9091815123853236 and 1041913173657237 in the request selection interface 503 are also related and will not be elaborated upon here.

[0154] Optional, such as Figure 5A As shown, the push configuration interface 501 may also include an environment information option, allowing debuggers to select the environment for initiating the data push test request. Optionally, such as... Figure 5A As shown, the push configuration interface 501 may also include a proxy processing option, allowing debuggers to choose whether to include proxy processing information in the data push test request. Optionally, such as... Figure 5A As shown, the push configuration interface 501 may also include a device address option, allowing debugging personnel to select the terminal device to initiate the data push test request. Optionally, the push configuration interface 501 may also include other configuration options regarding the object, push bit, initiation environment, etc., which are not limited.

[0155] After the debugger selects a push position (i.e., a specified push position) in the request selection interface 503, the interface will return to the push configuration interface 501. The debugger can then click the "One-Click Diagnosis" button 504. At this point, the server will respond to the "One-Click Diagnosis" selection, generate a data push test request based on the data push request selected by the debugger, and respond to the data push test request, obtaining the whiteboard data generated during the recall process of the push data from the push database to the specified push position. Afterwards, the server will call the aforementioned rule engine module to process the whiteboard data corresponding to the push data, obtaining the recall diagnosis results of the push data.

[0156] Finally, please see the appendix. Figure 5BThe diagram illustrates a display interface for recall diagnostic results. As shown in display interface 505, the recall diagnostic results include the reason why the pushed data could not be recalled, namely, the pushed data was not pushed to the specified push position, which did not satisfy the push logic, i.e., a mismatch in targeting, specifically a mismatch in targeting M. Display interface 505 also shows a solution: enabling the nomatch switch (the nomatch switch is a mismatch switch; enabling the nomatch switch means adding the information nomatch=true to the data push request) to skip the targeting. Display interface 505 also displays some detailed data about targeting M, i.e., data 506 to 508, to facilitate precise processing by debugging personnel.

[0157] Optionally, since the number of push data mentioned in step S201 may be one or more, please refer to the appendix. Figure 6A The diagram illustrates a display interface for the recall diagnostic results of multiple push data items. As shown in the diagnostic funnel information interface 601, the display of the recall diagnostic results of multiple push data items can simultaneously display the environment information of the specified push position that initiated the data push test request. For example, if the environment is a test environment, the IP address (Internet Protocol Address) of the test environment is "7.11.26.220:0330".

[0158] Optionally, the diagnostic funnel information interface 601 can also display object attributes, traffic attributes, and forced pull attributes. Object attributes can include one or more of the following: object name, object identifier, object identifier, etc. Traffic attributes can include the application type of the application to which the push position belongs, the push service type to which the push position belongs, etc.; for example, traffic attributes can be video, news, education, etc., without limitation. Forced pull attributes can include the associated push data of the specified push position.

[0159] Optionally, as shown in the request funnel section of the diagnostic funnel information interface 601, basic information about the specified push position, such as the supported material specifications, supported product types, supported bid types, and push position status, can also be displayed.

[0160] Supported material specifications can include the data type and specifications of the push data. For example, the data type can be images or videos, and the data size can be the size of an image or the specifications of a video. In the diagnostic funnel information interface 601, 123 indicates that the data type of the push data is an image, and 124 indicates that the data type of the push data is a video, meaning that the specified push position can display both images and videos. Supported product types refer to the types of external links that can be accessed after clicking the push data in the specified push position. For example, 12 in the diagnostic funnel information interface 601 can specify that the push position supports external link product types such as mini-programs in a certain session application. Supported bidding types refer to the price threshold required to display push data in the specified push position. Different bidding types indicate different price thresholds. Push position status refers to whether the push position is active or frozen, where setting 1 indicates an active push position and 0 indicates a frozen push position.

[0161] Furthermore, after receiving a data push test request for a specified push position, the push system retrieves multiple push data from the push database. These multiple push data then undergo recall, coarse ranking, fine ranking, and a winning stage. Only the winning push data is displayed in the specified push position. Therefore, as shown in the request funnel section of the diagnostic funnel information interface 601, the push data recall process can be presented in the form of a push data recall queue, which can be divided into recall, coarse ranking, fine ranking, and winning stages.

[0162] As shown in the diagnostic funnel information interface 601, the server responds to the data push test request for the push position through the push system. After obtaining 45 push data from the push database, these 45 push data enter the recall stage. After selection and retrieval, the recall stage does not filter the push data; therefore, the 45 push data enter the coarse ranking stage.

[0163] The coarse-ranking stage consists of two filtering stages. As shown in the diagnostic funnel information interface 601, 10 push notifications are filtered out in the first filtering stage, and no push notifications are filtered out in the second filtering stage. Next, the remaining 35 push notifications from the coarse-ranking stage are sent to the fine-ranking stage, where 32 push notifications are filtered out. Finally, the remaining 3 push notifications from the fine-ranking stage are sorted, and only the top-ranked push notification is output to the winning stage.

[0164] By using the push data recall queue in the diagnostic funnel information interface 601, the filtering status of push data can be seen intuitively and clearly, enabling debugging personnel to have a macroscopic understanding of the recall status of push data for a specified push position.

[0165] For further details, please see the appendix. Figure 6B The diagram illustrates an interface for filtering reasons during the coarse-sorting stage. After the debugger clicks on the relevant location in the coarse-sorting stage of the diagnostic funnel information interface 601, the interface jumps to interface 602. Interface 602 displays the IDs of the push data filtered during the coarse-sorting stage, as well as the filter codes for each push data. Different filter codes indicate different reasons for non-recovery. Optionally, clicking on any push data ID allows the debugger to further display the corresponding push data content. Optionally, clicking on any filter code allows the debugger to further display the reason for non-recovery indicated by the corresponding filter code.

[0166] For further details, please see the appendix. Figure 6C The diagram illustrates an interface for displaying filtering reasons during the fine-tuning stage. After the debugger clicks on the relevant location in the fine-tuning stage of the diagnostic funnel information interface 601, the interface jumps to interface 603. Interface 603 displays the IDs of the push data filtered during the fine-tuning stage, the target audience for each push data, the product type for each push data, and the filter code for each push data. The target audience refers to the object that pays to have push data placed in the push slot. Optionally, after the debugger clicks on any push data ID, any target audience, any product type, or any filter code, the data content of the corresponding push data, the object attributes of the corresponding target audience, the type of external link indicated by the corresponding product type, or the reason for the inability to recall the push data indicated by the corresponding filter code can be further displayed.

[0167] In this embodiment, by determining whether the semantics of key data fields in the whiteboard data match the push logic indicated by the target push rule, the reasons for the inability to recall push data can be autonomously identified. This avoids the need for manual analysis of whiteboard data to troubleshoot problems, greatly improving troubleshooting efficiency and reducing costs. Furthermore, this embodiment filters multiple push rules, only proceeding to the next step if the target push rule is selected. Therefore, this embodiment further improves troubleshooting efficiency by accurately selecting the target push rule suitable for a specific push position.

[0168] Furthermore, since the matching results of the push logic indicated by some push rules and the corresponding fields in the whiteboard data may affect the matching results of the push logic indicated by other push rules and the corresponding fields in the whiteboard data, the embodiments of this application select the target push rules that are adapted to the push range information in a preset order, which makes the investigation more accurate and helps to improve the accuracy of the recall diagnosis results.

[0169] In one embodiment of this application, another data processing method for push data recall is provided, which can be applied to... Figure 1 The data processing system for push data retrieval shown can be executed by a terminal device or a server, or by both. In this embodiment, the method is described using the server as an example. Figure 7 The diagram illustrates a flowchart of another data processing method for push data retrieval. This data processing method for push data retrieval... Figure 2 and Figure 3 The method shown is an extension of the one presented.

[0170] The details of S701 to S708 are as follows:

[0171] S701. Obtain the object identifier information of the specified object and the push position identifier information of the specified push position.

[0172] In this embodiment of the application, the specific method for obtaining the object identifier information of a specified object and the push position identifier information of a specified push position may be as follows: displaying a push configuration interface containing object configuration options; then, responding to the editing operation of the object configuration options, obtaining the configured object identifier information of the specified object; subsequently, obtaining multiple recommendation positions that the specified object has browsed during the use of the application software, and displaying the recommendation position identifier information of the multiple recommendation positions obtained; finally, responding to the selection operation of the multiple recommendation position identifier information obtained, obtaining the recommendation position identifier information of the selected specified recommendation position.

[0173] In one embodiment, the objects stored in the object request database can be colored objects, i.e., objects that have been whitelisted by the debugger and used in the application software. Specifically, the object request database can be an Eagle Eye platform (an object data visualization system capable of querying data push requests for colored objects).

[0174] S702. Based on the object identifier information and the push position identifier information, search the object request database for historical data push requests initiated by the specified object through the specified push position.

[0175] In this embodiment, the object request database is used to store historical data push requests initiated by multiple objects through multiple push positions. The specified object, push position, and historical data push request are stored correspondingly in the object database. Therefore, based on the obtained object identifier information and push position identifier information, the historical data push request initiated by a specified object through a specified push position can be retrieved from the object request database.

[0176] In one embodiment, it is possible that the specified object obtained by the debugger by editing the object configuration option in the push configuration interface is not the colored object, and the object request database only stores the historical data push requests corresponding to the colored object. In this case, the historical data push request for the specified object cannot be found in the object request database.

[0177] Therefore, optionally, if no historical data push request initiated by a specified object through a specified push position is found in the object request database, a data push request matching the push position identifier information can be obtained from the online request database used to store historical data push requests initiated through multiple push positions. The obtained data push request is used to retrieve push data for the specified push position. Finally, a data push test request is generated based on the obtained historical data push request. In specific implementations, the online request database can be a data warehouse, i.e., an online request sampling system, which can query the actual data push requests of online objects based on the push position.

[0178] S703. Generate a data push test request based on the found historical data push requests.

[0179] In this embodiment, different data push requests may be written using different request protocols, and the location of debug fields varies across these protocols. This makes the process of the server automatically modifying the data push request into a debug-state data push test request very complex and difficult to adapt to different request protocols.

[0180] Therefore, the specific way to generate a data push test request based on the found historical data push request can be as follows: convert the data format of the found historical data push request into the target data format to obtain the converted data push request; modify the parameters of the target field in the converted data push request to the preset debugging parameters to obtain the modified data push request; and generate a data push test request based on the modified data push request.

[0181] Here, the target field refers to the field containing "debug," and the default debug parameter is "true," i.e., debug = true. Since data push requests written using various commonly used request protocols can be converted into three main data formats—Query parameters, JSON strings (JavaScript Object Notation, a lightweight data exchange format), and Pb strings (Protocol Buffer, an efficient method for serializing structured data)—and Pb strings require the original request protocol to parse, thus enabling modification of the data push request, the target data format can be set to Query parameters and / or JSON strings. Because Query parameters or JSON strings are in key-value format (i.e., a one-to-one correspondence between fields and parameters), converting the data push request to the target data format only requires modifying the parameters of the target field to put the data push request into debug mode.

[0182] Furthermore, the specific method for generating a data push test request based on the modified data push request can be as follows: obtain the push service type to which the specified push position belongs; obtain the request protocol corresponding to the push service type based on the pre-established correspondence between push service types and request protocols; and process the modified data push request based on the request protocol to generate a data push test request.

[0183] Specifically, processing the modified data push request based on the request protocol to generate a data push test request involves rewriting the modified data push request according to the format requirements specified in the request protocol to generate a data push test request.

[0184] Furthermore, the push service type falls under the traffic attribute mentioned in the example of step S306. Since the request protocol is usually related to the push service type to which the specified push position belongs, and the modified data push request still needs to be packaged into a request that can actually be initiated through the request protocol, it is necessary to find the corresponding request protocol to process the modified data push request in order to finally generate the data push test request.

[0185] It should be noted that the specific implementation method for generating a data push test request based on the obtained historical data push request in step S702 can be found in the specific implementation method for generating a data push test request based on the obtained historical data push request, and will not be repeated here.

[0186] S704. Respond to the data push test request for the specified push position, and obtain the whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform.

[0187] In this embodiment, the server needs to initiate a data push test request before responding to the data push test request. Therefore, before step S704, the push service type to which the specified push bit belongs can be obtained; the request protocol corresponding to the push service type can be obtained based on the pre-established correspondence between push service types and request protocols; the packet transmission protocol corresponding to the request protocol can be obtained based on the pre-established correspondence between request protocols and packet transmission protocols; and the data push test request can be initiated based on the packet transmission protocol.

[0188] Specifically, the request protocol is usually related to the push service type to which the specified push position belongs, while the packet sending protocol is associated with the request protocol. Therefore, it is necessary to find the corresponding request protocol based on the push service type to which the specified push position belongs, and then find the appropriate packet sending protocol based on the request protocol. In specific implementations, the packet sending protocol corresponding to the request protocol can be a Hypertext Transfer Protocol (HTTP), a Remote Procedure Call (RPC) protocol, or svrkitrpc (a remote transmission protocol based on RPC) and other packet sending protocols.

[0189] Furthermore, the specific implementation method for obtaining whiteboard data in step S704 can be found in the specific implementation method of step S201 in the above embodiments, and will not be repeated here.

[0190] S705. Obtain the target push rule that matches the specified push position from multiple push rules through the diagnostic platform.

[0191] In this application embodiment, the specific implementation of step S705 can be found in the specific implementation of steps S202 and steps S302 to S304 in the above embodiment, and will not be repeated here.

[0192] S706. Obtain the key data fields in the whiteboard data that match the target push rule.

[0193] In this embodiment, the specific implementation of step S706 can be found in the specific implementation of step S203 in the above embodiment, and will not be repeated here.

[0194] S707. If the semantics of the key data fields do not match the push logic indicated by the target push rule, it is determined that the push data has not been pushed to the specified push position, and a recall diagnosis result for the push data not being pushed to the specified push position is generated according to the push logic indicated by the target push rule.

[0195] In this embodiment, the specific implementation of step S707 can be found in the specific implementation of step S204 in the above embodiment, and will not be repeated here.

[0196] S708, Output the recall diagnosis results of the pushed data.

[0197] In this embodiment, the specific implementation of step S708 can be found in the specific implementations of steps S205 and S307 in the above embodiments, and will not be repeated here.

[0198] In this embodiment, a data push test request can be automatically generated based on the found historical data push requests. This eliminates the need for debuggers to manually modify the data push request to debug mode, improving troubleshooting efficiency and reducing time and labor costs. Furthermore, this embodiment also allows for the autonomous initiation of a data push test request by finding a suitable packet transmission protocol for a specified push position, further enhancing troubleshooting efficiency and reducing time and labor costs.

[0199] In one embodiment of this application, another data processing system for push data retrieval is provided, which can be found in [reference needed]. Figure 8 , Figure 8 The data processing system for push data retrieval shown may include a terminal device 801, a diagnostic server 802, and a push server 803. A communication connection is established between the diagnostic server and the terminal device, and a communication connection is established between the push server and the diagnostic server.

[0200] The terminal device 801 may include any one or more of the following: smartphone, tablet, laptop, desktop computer, smart TV, smart vehicle, and smart wearable device. The terminal device 801 runs a diagnostic platform and may also run multimedia playback clients, social media clients, browser clients, etc., without limitation.

[0201] The diagnostic server 802 runs a diagnostic platform. The diagnostic server 802 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The push server 803 runs a push service platform. The push server 803 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. The terminal device 801 and the diagnostic server 802, as well as the diagnostic server 802 and the push server 803, can communicate directly or indirectly via wired or wireless communication; this application does not impose any restrictions on this.

[0202] In one embodiment of this application, another data processing method for push data recall is provided, which can be applied to... Figure 8 The data processing system for push data retrieval shown can be jointly executed by a terminal device, a diagnostic server, and a push server. In this embodiment, the method is illustrated by example, where the method is executed by a diagnostic platform running on the diagnostic server and a push service platform running on the push server. Figure 9 The diagram illustrates a data processing method for push data retrieval. S901 to S910 are described in detail below:

[0203] S901, The diagnostic platform obtains historical data push requests initiated by a specified object through a specified push position from the object database.

[0204] In this embodiment, the diagnostic platform can first receive the object identifier information of the specified object and the push position identifier information of the specified push position sent by the terminal device. Then, the diagnostic platform can search the object request database for historical data push requests initiated by the specified object through the specified push position based on the object identifier information and the push position identifier information.

[0205] In addition, the terminal device runs a diagnostic platform client, which can include a push configuration interface. The terminal device can then respond to the debugging personnel's editing and selection operations on the push configuration interface to obtain the object identification information of the specified object and the push bit identification information of the specified push bit.

[0206] In addition, the specific implementation of step S901 can be found in the specific implementation of steps S701 and S702, and will not be repeated here.

[0207] S902. The diagnostic platform generates a data push test request for a specified push position based on the historical data push requests found.

[0208] In this application embodiment, the specific implementation method for the diagnostic platform to generate data push test requests can be found in the specific implementation method of step S703, and will not be repeated here.

[0209] Optionally, the push service platform running on the push server can provide a format conversion service to convert the data format of the data push request into the target data format. Therefore, the specific method by which the diagnostic platform generates the data push test request could be as follows: The diagnostic platform sends the found historical data push requests to the push service platform, which then calls the format conversion service to convert the data format of the found historical data push requests into the target data format, obtaining the converted data push request; then, the diagnostic platform receives the converted data push request returned by the push service platform; subsequently, the diagnostic platform modifies the parameters of the target field in the converted data push request to preset debugging parameters, obtaining the modified data push request; finally, the diagnostic platform generates a data push test request based on the modified data push request.

[0210] The specific method for generating a data push test request based on the modified data push request can be as follows: obtain the push service type to which the specified push position belongs; obtain the request protocol corresponding to the push service type based on the pre-established correspondence between push service types and request protocols; and process the modified data push request based on the request protocol to generate a data push test request.

[0211] Optionally, the diagnostic platform can first determine whether the data format of the found historical data push request is the target data format. If not, the found historical data push request is sent to the push service platform so that the push service platform can perform subsequent steps. If it is, the diagnostic platform can directly modify the parameter of the target field in the historical data push request to the preset debugging parameter to obtain the modified data push request, and generate a data push test request based on the modified data push request.

[0212] For practical applications, please refer to the appendix. Figure 10 This diagram illustrates a process for generating a data push test request. The target data format can be set to JSON. After receiving the historical data push request, the diagnostic platform running on the diagnostic server will call... Figure 10 The standardization service shown sends the historical data push request to the push service platform in the push server. The push service platform then calls the Pb / Json conversion service to convert the data format of the historical data push request into JSON, resulting in a JSON format data push request.

[0213] In addition, such as Figure 10 As shown, the push service platform's protocol file stores the request protocols used by all push positions, and the request protocols in the protocol file are correlated with the push service types. Therefore, the push service platform can also find the corresponding target request protocol based on the push service type of the specified push position that initiated the historical data push request, and send the target request protocol to the protocol adapter in the diagnostic platform. Optionally, the push service platform can send the target request protocol to the protocol adapter in the diagnostic platform via the Pb / Json conversion service.

[0214] like Figure 10 As shown, after the request standardization service in the diagnostic platform obtains the data push request in JSON format, it sends the JSON data push request to the protocol adapter. The protocol adapter processes the JSON data push request according to the target request protocol sent by the push service platform, and finally obtains the data push test request.

[0215] Specifically, the diagnostic platform in the diagnostic server can directly store all the various request protocols used by the push requests, and then convert, parse, and process the data push requests. However, since the push service platform in the push server is the actual platform for managing the protocol files, the diagnostic platform can only store a copy of the protocol files. Once there is a request protocol update in the protocol files, the copy in the diagnostic platform will experience an update delay, which may lead to conversion failures, parsing failures, and processing failures (i.e., protocol consistency issues). Therefore, adding a format conversion service to the push service platform can improve the success rate of generating data push test requests.

[0216] S903, the diagnostic platform sends the data push test request to the push service platform.

[0217] In this embodiment, the diagnostic platform can directly send the data push test request to the push service platform. Optionally, to further enhance data security, the diagnostic platform can first encrypt the data push test request, and then send the encrypted data push test request to the push service platform. Optionally, other methods can also be used to send the data push test request, which will not be elaborated here.

[0218] S904. The push service platform obtains the packet sending protocol corresponding to the specified push position.

[0219] In this embodiment of the application, since the request protocol is usually related to the push service type to which the specified push position belongs, and the packet sending protocol is associated with the request protocol, it is necessary to find the corresponding request protocol according to the push service type to which the specified push position belongs, and then find the appropriate packet sending protocol according to the request protocol.

[0220] Therefore, the specific way for the push service platform to obtain the packet sending protocol corresponding to a specified push position can be as follows: obtain the push service type to which the specified push position belongs; obtain the request protocol corresponding to the push service type based on the pre-established correspondence between push service types and request protocols; and obtain the packet sending protocol corresponding to the request protocol based on the pre-established correspondence between request protocols and packet sending protocols.

[0221] S905, the push service platform initiates a data push test request based on the packet sending protocol.

[0222] In this embodiment of the application, since the data push test request is used to obtain push data for a specified push position, and the push database and the push system used for push data retrieval may not run in the push service platform; therefore, the specific way in which the push service platform initiates the data push test request based on the packet sending protocol can be: the push service platform sends the data push test request to the destination server according to the data transmission method indicated by the packet sending protocol, wherein the destination server runs the push database and the push system.

[0223] S906. The whiteboard data generated during the process of the push service platform obtaining push data from the push database to the specified push position.

[0224] In this embodiment, since step S201 mentions that the whiteboard data is included in the data return packet, and step S905 mentions that the push database and push system run on the destination server, the push service platform can receive the data return packet returned by the destination server to obtain the whiteboard data corresponding to the push data. Specifically, the destination server responds to the data push test request, retrieves the push data from the push database, and then processes the push data according to the order of the various modules in the push system, obtaining the processing data of each module during the processing to generate the data return packet.

[0225] In addition, the specific implementation method for obtaining whiteboard data in step S906 can also be found in the specific implementation method of step S201 in the above embodiments, which will not be repeated here.

[0226] For practical applications, please refer to the appendix. Figure 11 This diagram illustrates a process for obtaining data response packets. For details on generating the data push test request, please refer to [link to documentation / document / etc.]. Figure 10 The specific details of the examples are not elaborated here.

[0227] like Figure 11 As shown, the diagnostic platform integrates a packet sending proxy module 1101, and the push service platform integrates a packet sending service module 1102. The packet sending service includes three packet sending protocols: HTTP, RPC, and svrkitrpc.

[0228] After receiving the data push test request from the protocol adapter, the packet sending proxy module 1101 will send the data push test request to the packet sending service module 1102. The packet sending service module 1102 will receive the target request protocol sent by the protocol file and find the target packet sending protocol that matches the target request protocol. Then, as... Figure 11 As shown, the packet sending service module 1102 will send a data push test request to the destination server 1103 in accordance with the target packet sending protocol.

[0229] Subsequently, the destination server 1103 responds to the data push test request, retrieves the push data from the push database, and then processes the push data according to the order of the various modules in the push system. During the processing, it acquires the processing data from each module to generate a data response packet. Finally, the packet sending service module 1102 receives the data response packet returned by the destination server 1103 and sends it to the packet sending proxy module 1101 of the diagnostic platform. This allows the diagnostic platform to obtain the recall diagnostic results of the push data based on the whiteboard data in the data response packet.

[0230] Similarly, by integrating a packet sending service into the push service platform, the protocol consistency issue between the two platforms mentioned in step S902 can be avoided, thereby increasing the success rate of data push test requests.

[0231] S907, The diagnostic platform receives whiteboard data returned by the push service platform.

[0232] In this embodiment of the application, the diagnostic platform can first receive a data packet containing whiteboard data, and then obtain the whiteboard data by parsing the data packet.

[0233] S908, the diagnostic platform obtains the target push rule that matches the specified push position from multiple push rules.

[0234] In this application embodiment, the specific implementation of step S908 can be found in the specific implementation of steps S202, S302 to S304 in the above embodiment, and will not be repeated here.

[0235] S909. The diagnostic platform retrieves key data fields from the whiteboard data that match the target push rules.

[0236] In this embodiment, the specific implementation of step S909 can be found in the specific implementation of step S203 in the above embodiment, and will not be repeated here.

[0237] S910. If the semantics of the key data fields do not match the push logic indicated by the target push rule, the diagnostic platform determines that the push data has not been pushed to the specified push position, and generates a recall diagnostic result for the push data not being pushed to the specified push position according to the push logic indicated by the target push rule.

[0238] In this embodiment, the specific implementation of step S910 can be found in the specific implementation of step S204 in the above embodiment, and will not be repeated here.

[0239] S911, the diagnostic platform outputs the recall diagnostic results of the pushed data.

[0240] In this application embodiment, the specific implementation of step S911 can be found in the specific implementation of steps S205 and S307 in the above embodiment, and will not be repeated here.

[0241] In this embodiment, the diagnostic platform automatically generates data push test requests, eliminating the need for debugging personnel to manually modify the data push requests to debug mode. This improves troubleshooting efficiency and reduces time and labor costs. Furthermore, this embodiment also allows the push service platform to find suitable packet transmission protocols for specified push positions and initiate data push test requests autonomously, further enhancing troubleshooting efficiency and reducing time and labor costs.

[0242] Furthermore, by integrating the packet sending service and format conversion service into the push service platform of the push server in this application embodiment, the protocol inconsistency problem can be effectively avoided, resulting in a higher success rate of automatically obtaining whiteboard data, thereby improving the overall investigation efficiency and success rate.

[0243] This application describes an apparatus embodiment that can be used to execute the data processing method for push data recall in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the data processing method for push data recall described above.

[0244] This application provides a data processing device for push data recall, such as... Figure 12 As shown, the device includes an acquisition unit 1201, a processing unit 1202, and an output unit 1203, wherein:

[0245] The acquisition unit 1201 is used to respond to a data push test request for a specified push position and acquire whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform.

[0246] The processing unit 1202 is used to obtain a target push rule that matches the specified push position from multiple push rules through a diagnostic platform; different push rules indicate different push logic.

[0247] The processing unit 1202 is also used to obtain key data fields in the whiteboard data that match the target push rule;

[0248] The processing unit 1202 is further configured to determine that the data has not been pushed to the specified push position if the semantics of the key data field does not match the push logic indicated by the target push rule, and generate a recall diagnosis result that the data has not been pushed to the specified push position according to the push logic indicated by the target push rule.

[0249] Output unit 1203 is used to output the recall diagnosis result of the push data; the recall diagnosis result is used to indicate the push logic that is not satisfied when the push data is not pushed to the specified push position.

[0250] In one embodiment of this application, based on the aforementioned scheme, when the processing unit 1202 obtains a target push rule matching the specified push position from multiple push rules through a diagnostic platform, it can specifically be used to: obtain push range information of the specified push position through the diagnostic platform; wherein, the push range information includes at least one of the following: associated push data of the specified push position, push position information of the specified push position, application identifier information of the application to which the specified push position belongs, and environment identifier information of the initiating environment in which the specified push position initiates the data push request; obtain candidate push rules from the multiple push rules, and adaptation range information of the candidate push rules; if the adaptation range information of the candidate push rule matches the push range information, then the candidate push rule is determined as the target push rule.

[0251] In one embodiment of this application, the plurality of push rules are arranged in a preset order. Based on the aforementioned scheme, when the processing unit 1202 obtains the target push rule matching the specified push position from the plurality of push rules through the diagnostic platform, it can specifically be used to: obtain the push range information of the specified push position through the diagnostic platform; select push rules sequentially according to the arrangement order of the plurality of push rules, and match the adaptation range information of the selected push rules with the push range information until the adaptation range information of the selected push rules matches the push range information; and take the push rule whose adaptation range information matches the push range information as the target push rule.

[0252] In one embodiment of this application, based on the aforementioned scheme, the processing unit 1202 can be further configured to: concatenate the key data fields with the target push rule to obtain concatenated text; perform semantic correlation recognition processing on the concatenated text to obtain the semantic correlation between the key data fields and the target push rule; if the semantic correlation is less than or equal to a preset correlation threshold, then determine that the semantics of the key data fields do not match the push logic indicated by the target push rule.

[0253] In one embodiment of this application, based on the aforementioned scheme, the plurality of push rules are arranged in a preset order; the processing unit 1202 can also be used to: if the semantics of the data key field matches the push logic indicated by the target push rule, then the push rule arranged after the target push rule and matching the specified push position is taken as the new target push rule; obtain the new data key field in the whiteboard data that matches the new target push rule; when the semantics of the new data field does not match the push logic indicated by the new target push rule, determine that the push data has not been pushed to the specified push position, and generate a recall diagnosis result of the push data according to the push logic indicated by the new target push rule.

[0254] In one embodiment of this application, based on the foregoing scheme, the acquisition unit 1201 can also be used to: acquire object identification information of a specified object and push position information of the specified push position; search for historical data push requests initiated by the specified object through the specified push position from the object request database according to the object identification information and the push position identification information; wherein, the object request database is used to store historical data push requests initiated by multiple objects through multiple push positions; and generate the data push test request based on the found historical data push requests.

[0255] In one embodiment of this application, based on the foregoing scheme, the acquisition unit 1201 can also be used to: if no historical data push request initiated by the specified object through the specified push position is found in the object request database, then obtain a data push request matching the push position identifier information from the online request database used to store historical data push requests initiated through multiple push positions; wherein, the acquired data push request is used to obtain push data for the specified push position; and the data push test request is generated based on the acquired historical data push request.

[0256] In one embodiment of this application, based on the aforementioned scheme, when the acquisition unit 1201 generates the data push test request based on the found historical data push request, it can specifically be used to: convert the data format of the found historical data push request into a target data format to obtain a converted data push request; modify the parameter of the target field in the converted data push request to a preset debugging parameter to obtain a modified data push request; and generate the data push test request based on the modified data push request.

[0257] In one embodiment of this application, based on the foregoing scheme, when the acquisition unit 1201 generates the data push test request based on the modified data push request, it can be specifically used to: acquire the push service type to which the specified push position belongs; acquire the request protocol corresponding to the push service type based on the pre-established correspondence between the push service type and the request protocol; and process the modified data push request based on the request protocol to generate the data push test request.

[0258] In one embodiment of this application, the data processing device for push data recall further includes a request initiation unit 1204; based on the aforementioned scheme, the request initiation unit 1204 can be used to: obtain the push service type to which the specified push position belongs; obtain the request protocol corresponding to the push service type based on a pre-established correspondence between push service types and request protocols; obtain the packet transmission protocol corresponding to the request protocol based on a pre-established correspondence between request protocols and packet transmission protocols; and initiate the data push test request based on the packet transmission protocol.

[0259] In one embodiment of this application, based on the foregoing scheme, when the acquisition unit 1201 responds to a data push test request for a specified push position and acquires the whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform, it can specifically be used to: send the data push test request to the push service platform so that the push service platform acquires the packet transmission protocol corresponding to the specified push position, initiates the data push test request based on the packet transmission protocol, acquires the whiteboard data, and receives the whiteboard data returned by the push service platform.

[0260] In one embodiment of this application, based on the aforementioned scheme, when outputting the recall diagnosis result of the push data, the output unit 1203 may specifically be used to: if the data push test request carries proxy processing data, send the recall diagnosis result of the push data to the proxy processing platform, so that the proxy processing platform obtains the push request modification method matching the recall diagnosis result of the push data, and modifies the data push request initiated by the specified push position according to the push request modification method.

[0261] It should be noted that the apparatus provided in the above embodiments and the method provided in the above embodiments belong to the same concept, and the specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0262] The apparatus provided in the above embodiments can be located within a terminal device or a server. By determining whether the semantics of key data fields in the whiteboard data match the push logic indicated by the target push rule, the apparatus can directly generate a recall diagnostic result for the push data based on the push logic indicated by the target push rule when the semantics of key data fields do not match. Therefore, this embodiment can autonomously identify the reasons for the inability to recall push data, avoiding the need for manual analysis of whiteboard data to troubleshoot problems, greatly improving troubleshooting efficiency and reducing time and labor costs. Furthermore, this embodiment filters multiple push rules, only those matching a specified push position are used as target push rules for further judgment; this avoids the need to logically compare multiple fields in the whiteboard data with multiple push rules one by one. Therefore, this embodiment further improves troubleshooting efficiency by accurately selecting target push rules suitable for a specified push position.

[0263] Embodiments of this application also provide an electronic device, including one or more processors and a storage device, wherein the storage device is used to store one or more computer programs, which, when executed by one or more processors, enable the electronic device to implement the data processing method for push data recall as described above.

[0264] Figure 13 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0265] It should be noted that, Figure 13 The computer system 1300 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0266] like Figure 13 As shown, the computer system 1300 includes a central processing unit (CPU) 1301, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on a program stored in read-only memory (ROM) 1302 or a program loaded from storage portion 1308 into random access memory (RAM) 1303. The RAM 1303 also stores various programs and data required for system operation. The CPU 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An input / output (I / O) interface 1305 is also connected to the bus 1304.

[0267] In some embodiments, the following components are connected to the I / O interface 1305: an input section 1306 including a keyboard, mouse, etc.; an output section 1307 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 1308 including a hard disk, etc.; and a communication section 1309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1309 performs communication processing via a network such as the Internet. A drive 1310 is also connected to the I / O interface 1305 as needed. A removable medium 1311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1310 as needed so that computer programs read from it can be installed into the storage section 1308 as needed.

[0268] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as a computer program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1309, and / or installed from removable medium 1311. When the computer program is executed by processor (CPU) 1301, it performs various functions defined in the system of this application.

[0269] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory, flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0270] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.

[0271] The units or modules described in the embodiments of this application can be implemented in software or hardware, and can also be located in a processor. The names of these units or modules do not necessarily limit the specific unit or module itself.

[0272] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the data processing method for push data retrieval as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently without being assembled into the electronic device.

[0273] Another aspect of this application provides a computer program product comprising a computer program stored in a computer-readable storage medium. A processor of an electronic device reads the computer program from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the data processing method for push data recall provided in the various embodiments described above.

[0274] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0275] Other embodiments of this application will readily conceive of by considering the specification and practicing the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0276] The above content is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A data processing method of push data recall, characterized in that, include: In response to a data push test request for a specified push position, the system obtains whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform. The whiteboard data includes the processing data of the push data by the modules within the push system during the recall process. The diagnostic platform obtains the target push rule that matches the specified push position from multiple push rules; different push rules indicate different push logic; Obtain the key data fields in the whiteboard data that match the target push rule; If the semantics of the key data field does not match the push logic indicated by the target push rule, it is determined that the push data has not been pushed to the specified push position, and a recall diagnosis result indicating that the push data has not been pushed to the specified push position is generated according to the push logic indicated by the target push rule. Output the recall diagnosis result of the pushed data; the recall diagnosis result is used to indicate the push logic that is not satisfied when the pushed data is not pushed to the specified push position.

2. The method of claim 1, wherein, The step of obtaining the target push rule that matches the specified push position from multiple push rules through the diagnostic platform includes: The push range information of the specified push position is obtained through the diagnostic platform; wherein, the push range information includes at least one of the following: the associated push data of the specified push position, the push position information of the specified push position, the application identifier information of the application to which the specified push position belongs, and the environment identifier information of the initiating environment in which the specified push position initiates the data push test request. Obtain candidate push rules and their adaptation range information from the plurality of push rules; If the adaptation range information of the candidate push rule matches the push range information, then the candidate push rule is determined as the target push rule.

3. The method of claim 1, wherein, The multiple push rules are arranged in a preset order; the step of obtaining the target push rule matching the specified push position from the multiple push rules through the diagnostic platform includes: Obtain the push range information of the specified push position through the diagnostic platform; According to the order of the multiple push rules, push rules are selected in sequence, and the adaptation range information of the selected push rules is matched with the push range information until the adaptation range information of the selected push rules matches the push range information. The push rule that matches the adaptation range information with the push range information is taken as the target push rule.

4. The method of claim 1, wherein, The method further includes: The key data fields are concatenated with the target push rule to obtain the concatenated text; The concatenated text is subjected to semantic correlation recognition processing to obtain the semantic correlation between the key data fields and the target push rule; If the semantic relevance is less than or equal to a preset relevance threshold, then it is determined that the semantics of the key data field does not match the push logic indicated by the target push rule.

5. The method of claim 1, wherein, The multiple push rules are arranged in a preset order; the method further includes: If the semantics of the key data field matches the push logic indicated by the target push rule, then the push rule that is arranged after the target push rule and matches the specified push position will be used as the new target push rule. Obtain new key data fields from the whiteboard data that match the new target push rule; When the semantics of the new data field do not match the push logic indicated by the new target push rule, it is determined that the push data has not been pushed to the specified push position, and a recall diagnostic result of the push data is generated according to the push logic indicated by the new target push rule.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the object identifier information of the specified object, and the push bit identifier information of the specified push bit; Based on the object identification information and the push position identification information, the historical data push request initiated by the specified object through the specified push position is retrieved from the object request database; wherein, the object request database is used to store historical data push requests initiated by multiple objects through multiple push positions; Based on the historical data push requests found, the data push test request is generated.

7. The method of claim 6, wherein, The method further includes: If no historical data push request initiated by the specified object through the specified push position is found in the object request database, then a historical data push request matching the push position identifier information is obtained from the online request database used to store historical data push requests initiated through multiple push positions; wherein, the obtained historical data push request is used to obtain push data for the specified push position; Based on the obtained historical data push requests, the data push test request is generated.

8. The method of claim 6, wherein, The process of generating the data push test request based on the found historical data push request includes: The data format of the found historical data push request is converted into the target data format to obtain the converted data push request; The parameters of the target field in the converted data push request are modified to preset debugging parameters to obtain the modified data push request; Based on the modified data push request, the data push test request is generated.

9. The method of claim 8, wherein, The process of generating the data push test request based on the modified data push request includes: Obtain the push service type to which the specified push position belongs; Based on the pre-established correspondence between push service types and request protocols, obtain the request protocol corresponding to the push service type; Based on the aforementioned request protocol, the modified data push request is processed to generate the data push test request.

10. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the push service type to which the specified push position belongs; Based on the pre-established correspondence between push service types and request protocols, obtain the request protocol corresponding to the push service type; Based on the pre-established correspondence between request protocols and packet sending protocols, obtain the packet sending protocol corresponding to the request protocol; Based on the packet sending protocol, the data push test request is initiated.

11. The method according to any one of claims 1 to 5, characterized in that, The response to the data push test request for the specified push position obtains the whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform, including: The data push test request is sent to the push service platform so that the push service platform can obtain the packet sending protocol corresponding to the specified push position, initiate the data push test request based on the packet sending protocol, and obtain the whiteboard data. Receive the whiteboard data returned by the push service platform.

12. The method according to any one of claims 1 to 5, characterized in that, The output of the recall diagnostic results of the pushed data includes: If the data push test request carries proxy processing information, the recall diagnosis result of the push data is sent to the proxy processing platform so that the proxy processing platform can obtain the push request modification method that matches the recall diagnosis result of the push data, and modify the data push request initiated by the specified push position according to the push request modification method.

13. A data processing apparatus for push data recall, characterized by, It includes an acquisition unit, a processing unit, and an output unit, wherein: The acquisition unit is used to respond to a data push test request for a specified push position, and to acquire whiteboard data generated during the recall process of push data from the push database to the specified push position through the push service platform. The whiteboard data includes the processing data of the push data by the modules in the push system during the recall process. The processing unit is used to obtain a target push rule that matches the specified push position from multiple push rules through a diagnostic platform; different push rules indicate different push logic. The processing unit is also used to obtain key data fields in the whiteboard data that match the target push rule; The processing unit is further configured to determine that the push data has not been pushed to the specified push position if the semantics of the key data field does not match the push logic indicated by the target push rule, and generate a recall diagnosis result that the push data has not been pushed to the specified push position according to the push logic indicated by the target push rule. The output unit is used to output the recall diagnosis result of the push data; the recall diagnosis result is used to indicate the push logic that is not satisfied when the push data is not pushed to the specified push position.

14. A computer storage medium, characterized in that, The computer storage medium stores one or more computer programs, which are adapted to be loaded by a processor and executed by the data processing method for push data recall as described in any one of claims 1 to 12.

15. An electronic device, comprising: include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the data processing method for push data recall as described in any one of claims 1 to 12.

16. A computer program product, characterised in that, The computer program product includes a computer program adapted to be loaded by a processor and executed by the data processing method for push data recall as described in any one of claims 1 to 12.

Images