A message push method, apparatus and storage medium

Abstract

This invention provides a message push method, apparatus, and storage medium. The method includes: upon receiving a message to be pushed to a target user, determining whether the target user has a push time window; if the target user does not have a push time window, creating a push time window corresponding to the target user, starting from the time point when the message to be pushed is received; adding all messages to be pushed received within the push time window and sent to the target user to a push message set corresponding to the push time window; and when the push time window ends, selecting a message to be pushed that meets preset conditions from the push message set as a target push message and sending the target push message to the target user.

Description

Technical Field

[0001] This invention relates to the field of social media push notifications, and more particularly to a push notification method, apparatus, and storage medium. Background Technology

[0002] Weibo's current push notification scenarios primarily rely on two types of computing scenarios for delivery:

[0003] Offline push: Due to the massive number of users, existing offline mixed-data systems divide all users into several user packets. Each user packet is processed sequentially at fixed time intervals. For all push messages received within that fixed time interval for users within that packet, the best-performing message is selected and sent to the corresponding user. Since each user can only exist in a fixed user packet, each full-user calculation requires a fixed time interval, resulting in poor real-time performance of offline push. However, the advantage is selective delivery, leading to relatively high-quality push content. Current scenarios primarily use Spark for offline computation and push, but this offline task is cumbersome and resource-intensive, taking only one hour to cover all users, resulting in low user delivery timeliness.

[0004] Direct push notifications: These notifications are calculated and delivered in real-time based on scenarios or user behavior. Because they do not participate in algorithmic competition and are calculated in real time, direct push notifications have good delivery timeliness, but the disadvantage is that content quality is not easy to guarantee. Direct push notifications deliver to users with high timeliness, but the effect is uncontrollable, and the quality of the current material can only be judged by some prior experience.

[0005] In the process of developing this invention, the applicant discovered at least the following problems in the prior art:

[0006] Existing offline push notifications suffer from poor timeliness, and the quality of directly sent push content is difficult to guarantee. Summary of the Invention

[0007] This invention provides a message push method, apparatus, and storage medium to solve the problems of poor timeliness of existing offline push and difficulty in guaranteeing the quality of directly sent push content.

[0008] To achieve the above objectives, in a first aspect, embodiments of the present invention provide a message push method, comprising:

[0009] Upon receiving a message to be pushed to a target user, determine whether the target user is within a push time window;

[0010] If it is determined that the target user does not have a push time window, a push time window corresponding to the target user is created starting from the time point when the message to be pushed is received.

[0011] All messages to be pushed to the target user received within the push time window are added to the push message set corresponding to the push time window;

[0012] When the push time window ends, select a message that meets the preset conditions from the push message set as the target push message, and send the target push message to the target user.

[0013] Furthermore, the message to be pushed is sent to the target user by a business party, and the business party includes multiple parties; the message to be pushed includes slow push messages and / or direct push messages sent to the target user by the business party, wherein the slow push messages are received through a configured slow message channel, and the direct push messages are received through a configured direct message channel.

[0014] Further, the step of selecting a message to be pushed that meets preset conditions from the set of push messages as the target push message includes:

[0015] Based on the predicted click-through rate (CTR) of each message to be pushed in the push message set, messages to be pushed with a CTR greater than or equal to a preset CTR threshold are selected as target push messages; or, a set number of messages to be pushed with the highest predicted CTR are selected as target push messages.

[0016] Further, sending the target push message to the target user includes:

[0017] The target user is determined to be a daily active user based on a periodically updated list of all daily active users; wherein, a daily active user refers to a user who has engaged in activity on that day.

[0018] If the target user is determined to be a daily active user, the target push message is mixed and then sent to the target user through the first push channel;

[0019] If it is determined that the target user is not a daily active user, the target push message will be mixed and sent to the target user through the second push channel;

[0020] The message reach rate of the second push channel is greater than that of the first push channel.

[0021] Further, determining whether the target user is a daily active user based on the periodically updated list of all daily active users includes:

[0022] Use a Bloom filter to check whether the target user is recorded in the full list of daily active users;

[0023] If the target user is found to be recorded in the full list of daily active users, the target user is determined to be a daily active user.

[0024] If the target user is not recorded in the full list of daily active users, it is determined that the target user is not a daily active user.

[0025] Further, sending the target push message to the target user includes:

[0026] The user-related information of the target user stored in HDFS is read using Flink file streams; wherein, the user-related information of each user is pre-stored in HDFS in Parquet format;

[0027] The target push message is sent to the target user corresponding to the read user-related information.

[0028] Secondly, embodiments of the present invention provide a message push device, comprising:

[0029] The message receiving unit is used to determine whether the target user has a push time window when it receives a message to be sent to the target user;

[0030] The time window creation unit is used to create a push time window corresponding to the target user, starting from the time point when the message to be pushed is received, if it is determined that the target user does not have a push time window.

[0031] The push message collection unit is used to add all push messages received within the push time window and sent to the target user to the push message set corresponding to the push time window;

[0032] The push message sending unit is used to select a message to be pushed that meets preset conditions from the push message set as the target push message when the push time window ends, and send the target push message to the target user.

[0033] Furthermore, the message to be pushed is sent to the target user by a business party, and the business party includes multiple parties; the message to be pushed includes slow push messages and / or direct push messages sent to the target user by the business party, wherein the slow push messages are received through a configured slow message channel, and the direct push messages are received through a configured direct message channel.

[0034] Furthermore, the push message sending unit includes:

[0035] The first target push message selection module is used to select push messages with a predicted click-through rate greater than or equal to a preset click-through rate threshold as target push messages based on the predicted click-through rate corresponding to each push message in the push message set; or, select a set number of push messages with the highest predicted click-through rate as target push messages.

[0036] Furthermore, the push message sending unit includes:

[0037] The first daily active user determination module is used to determine whether the target user is a daily active user based on a periodically updated list of all daily active users; wherein, the daily active user refers to a user who has active operations on the current day;

[0038] The first sending module is used to, when it is determined that the target user is a daily active user, mix the target push message and send it to the target user through the first push channel;

[0039] The second sending module is used to send the target push message to the target user through the second push channel after mixing the target push messages if it is determined that the target user is not a daily active user.

[0040] The message reach rate of the second push channel is greater than that of the first push channel.

[0041] Furthermore, the first daily active user determination module includes:

[0042] The retrieval module is used to retrieve whether the target user is recorded in the full list of daily active users using a Bloom filter;

[0043] The second daily active user determination module is used to determine that the target user is a daily active user if the target user is found to be recorded in the full list of daily active users; and to determine that the target user is not a daily active user if the target user is not found to be recorded in the full list of daily active users.

[0044] Furthermore, the push message sending unit includes:

[0045] The user information acquisition module is used to read the user-related information of the target user stored in HDFS via Flink file stream; wherein, the user-related information of each user is pre-stored in HDFS in Parquet format;

[0046] The push message sending module is used to send the target push message to the target user corresponding to the read user-related information.

[0047] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of the first aspects.

[0048] The above technical solution has the following beneficial effects: by opening a push time window for the user, collecting push messages received for the user within the push time window, and selecting the best push messages from the collected push messages to send to the user at the end of the push time window, it improves real-time performance compared to offline push and improves the content quality of push messages compared to direct push, thereby balancing timeliness and content quality to improve user experience. Attached Figure Description

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

[0050] Figure 1 This is a flowchart of a message push method according to one embodiment of the present invention;

[0051] Figure 2 This is an architectural diagram of a message push device according to one embodiment of the present invention;

[0052] Figure 3 This is a schematic diagram illustrating the I / O throughput statistics based on existing Socket technology;

[0053] Figure 4 This is a schematic diagram illustrating the I / O throughput statistics after replacing Socket with Flink file stream, which is one of the embodiments of the present invention. Detailed Implementation

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

[0055] Firstly, such as Figure 1 As shown, an embodiment of the present invention provides a message push method, including:

[0056] Step S10: When a message to be pushed to the target user is received, determine whether the target user has a push time window.

[0057] Step S11: If it is determined that the target user does not have a push time window, a push time window corresponding to the target user is created starting from the time point when the message to be pushed is received.

[0058] Step S12: Add all messages to be pushed to the target user received within the push time window to the push message set corresponding to the push time window;

[0059] Step S13: When the push time window ends, select a message that meets the preset conditions from the push message set as the target push message, and send the target push message to the target user.

[0060] In some embodiments, a message push method is provided, which is adopted by a message push device. The length of the push time window can be determined according to the specific requirements for the real-time performance of message push, for example, it may include, but is not limited to, 10 minutes. Considering that in the prior art, offline mixed processing handles a batch of users every 10 minutes, all users are divided into 6 batches, and it would take one hour to process all users. In this embodiment, a push time window is created for each user, and each user processes messages in parallel within their own push time window. Therefore, this embodiment significantly improves the real-time performance of message push for each user. Within the push time window of the same user, one or more messages to be pushed from the same business party or multiple messages to be pushed from different business parties can be received. The preset conditions can be reasonably set according to specific needs. For example, they may include, but are not limited to, selecting one or more messages as target push messages based on the timeliness of the message to be pushed, the degree of matching between the content category of the message to be pushed and the user's behavioral characteristics, and the user's range of interests. The number of target push messages can be limited according to specific needs. For example, under certain needs, in order to protect the user experience, each user may be limited to receiving only 10 push messages per day. In this case, the number of target push messages that meet the preset conditions can be limited to 1, so as to select the optimal message to be pushed in the push time window and send it to the user.

[0061] Furthermore, the message to be pushed is sent to the target user by a business party, and the business party includes multiple parties; the message to be pushed includes slow push messages and / or direct push messages sent to the target user by the business party; wherein the slow push messages are received through a configured slow message channel, and the direct push messages are received through a configured direct message channel.

[0062] In some embodiments, slow push messages and direct push messages are defined according to the timeliness requirements of push messages in specific implementations. Push messages with high timeliness requirements, which are expected to be displayed to users as soon as possible, are processed as direct push messages. When the timeliness requirements of push messages are low and their arrival at users can be delayed, they are processed as slow push messages. In order to interface with systems that have already been deployed and are distinguishing between slow push messages and direct push messages, and to transfer the slow messages that the business originally sent to the offline mixed-signal system for processing to the message push device implemented in this embodiment for processing, this embodiment receives slow push messages that the business originally sent to the existing offline mixed-signal system through a slow message channel, and receives direct push messages from the business through a direct message channel. This embodiment receives slow push messages from various business parties sent to target users through a slow message channel. The slow message channel can be implemented by a message queue, including but not limited to Kafka. Using Kafka to implement the message queue to receive slow push messages addresses the problem of a large number of users being processed for slow push messages, and Kafka is used to achieve high throughput. The system receives direct push messages from various business units destined for the target user via a direct message channel, which can be implemented using Redis. A Redis queue receives these messages, which are then consumed by a Flink program. A message queue-based approach is provided for receiving slow push messages, facilitating integration with systems that use message queues for slow push messages. This replaces the existing method of polling user packets to process slow push messages, improving the real-time performance of slow push message processing in related systems. Receiving direct push messages via Redis also facilitates integration with Redis-based direct push message systems, thereby improving the content quality of direct push messages under preset constraints. When both slow and direct push messages from business units exist in the system, this embodiment can collect them into a single push time window and select the best option based on preset conditions. This improves the real-time performance of slow push message processing and enhances the quality of the target push message through the selection process, resulting in an overall improved user experience. Preferably, since direct push messages are delivered quickly and occupy users' daily delivery quota, but the quality is uncontrollable, business units can classify and process direct push messages by choosing between using the direct message channel or the old channel. High-priority materials, such as full-volume hotspots, are sent directly without entering real-time mixed sorting and continue to use the old channel. Direct messages with relatively unstable effects are handled by the message push device. This ensures delivery quality while sacrificing some timeliness, and at the same time avoids users' delivery quota from being quickly exhausted. This reduces the number of users opening the message and improves the user experience, reducing the proportion of users turning off the message.Compared to the slow push messages processed by offline mixed-signaling systems, this embodiment, by reasonably setting the length of the push time window, can ensure that slow push messages are delivered promptly and optimally according to preset conditions. For example, by implementing a 10-minute window at the uid granularity using FlinkTimeWindow (equivalent to the push time window corresponding to the user), it can ensure that uid-mid pairs within 10 minutes are aggregated and optimally delivered. Compared to the hour-level delay in existing offline mixed-signaling technologies, this can greatly improve the timeliness of materials reaching users. Many timely and high-quality microblogs have also achieved the goal of reaching users faster, increasing the overall user opening scale. Tests show that single-service delivery PV (page view) increased by 39.67%, click PV increased by 57.08%, and click-through rate increased by 12.46%. It can be seen that the improvement in timeliness has a significant impact on the opening scale and click-through rate of high-quality materials. FlinkTimeWindow is a functional component within the Flink framework.

[0063] Further, the step of selecting a message to be pushed that meets preset conditions from the set of push messages as the target push message includes:

[0064] Based on the predicted click-through rate (CTR) of each message to be pushed in the push message set, messages to be pushed with a CTR greater than or equal to a preset CTR threshold are selected as target push messages; or, a set number of messages to be pushed with the highest predicted CTR are selected as target push messages.

[0065] In some embodiments, the preset condition can be defined based on the click-through rate (CTR). Preferably, the CTR can be the predicted CTR, i.e., the predicted user click-through rate for the message to be pushed. The predicted CTR can be obtained in various ways. For example, the message push device can perform predictive analysis on the received message to be pushed based on the content of the message to be pushed to obtain the predicted CTR. Another example is that when the business pushes the message to be pushed to the message push device with uid-mid (where uid is the user ID and mid is the message ID), it also pushes the predicted CTR corresponding to the message to be pushed. That is, in addition to receiving the message to be pushed to the target user from various business parties, it also receives the predicted CTR corresponding to the message to be pushed. The preset condition can be defined as pushing the message to the user as the target message when the CTR corresponding to the message to be pushed is greater than or equal to a preset CTR threshold; otherwise, it is prohibited to push the message to the user. In this case, the target message may contain one or more messages to be pushed. For example, the click-through rate (CTR) can range from [0,1], and the preset CTR threshold is 0.005. Therefore, messages with a predicted CTR < 0.005 will be filtered out by the system, meaning a portion of low-quality pushes will be blocked and prevented from being sent to users, ensuring that the target push messages received by users are of high quality. A preset condition can also be defined as selecting the push message with the highest predicted CTR as the target push message. In this case, the target push message contains only one push message. In practice, the above two preset conditions can be implemented simultaneously or only one of them can be implemented. When implemented simultaneously, the specific preset condition can be selected through dynamic configuration or a configuration file. Here, uid represents the user's unique identifier, mid represents the message's unique identifier, and uid-mid represents the correspondence between the push message and the user. When there are multiple target push messages, they can be sorted according to their predicted CTR and sent in descending order of predicted CTR.

[0066] Further, sending the target push message to the target user includes:

[0067] The target user is determined to be a daily active user based on a periodically updated list of all daily active users; wherein, a daily active user refers to a user who has performed user actions on that day.

[0068] If the target user is determined to be a daily active user, the target push message is mixed and then sent to the target user through the first push channel; preferably, if the target user is determined to be a daily active user, the target push message is sent to the target user through the first push channel in descending order of the predicted click-through rate corresponding to the target push message;

[0069] If it is determined that the target user is not a daily active user, the target push message is mixed and then sent to the target user through the second push channel; preferably, if it is determined that the target user is not a daily active user, the target push message is sent to the target user through the second push channel in descending order of the predicted click-through rate corresponding to the target push message.

[0070] The message reach rate of the second push channel is greater than that of the first push channel.

[0071] In some embodiments, daily active users (DAUs) are users who engage in activities such as clicking and browsing during the current day, representing the user's activity level. The system obtains the user's DAU status and makes decisions based on the user's different daily statuses, then passes targeted push messages to downstream services. Downstream services can be backend services connected to the user or the user themselves. If the user is a DAU, the system primarily increases the push threshold to send high-quality targeted push messages, optimizing the user experience. If the user is not a DAU, the system primarily optimizes the push channel, selecting channels with high reach rates to improve efficiency and strive to convert the user into a DAU. The preset conditions are reasonably set according to specific needs. For example, they include, but are not limited to, selecting one or more messages as target push messages based on the timeliness of the message to be pushed, the degree of matching between the content category of the message to be pushed and the user's behavioral characteristics, and the user's range of interests. The number of target push messages can be limited according to specific needs. For example, under certain needs, in order to protect user experience, each user can only receive 10 push messages per day. In this case, the number of target push messages that meet the preset conditions can be limited to 1, so as to select the optimal message to be pushed in the push time window to send to the user. Preferably, the preset conditions can be defined based on the click-through rate (CTR). When the business pushes the message to be pushed (uid-mid, where uid is the user ID and mid is the message ID) to the message push device, it also pushes the user's predicted click-through rate corresponding to the message to be pushed. That is, in addition to receiving the messages to be pushed to the target user from various business parties, it also receives the click-through rate corresponding to the message to be pushed. Preferably, the click-through rate can be the user's predicted click-through rate, that is, the predicted user click-through rate for the message to be pushed. The preset condition can be defined as follows: when the click-through rate (CTR) of the message to be pushed is greater than or equal to a preset CTR threshold, the message to be pushed to the user is pushed as the target message; otherwise, the message to be pushed to the user is prohibited. In this case, the target message may contain one or more messages to be pushed. For example, the CTR range can be [0,1], and the preset CTR threshold is 0.005. Then, messages to be pushed with a CTR < 0.005 will be filtered by the system, i.e., filtering out some low-quality pushes and prohibiting them from being sent to the user, ensuring that the target message received by the user has high quality. The preset condition can also be defined as selecting the message to be pushed with the highest CTR as the target message. In this case, the target message contains only one message to be pushed. Here, uid represents the user's unique identifier, mid represents the message's unique identifier, and uid-mid represents the correspondence between the message to be pushed and the user. Furthermore, for target messages of daily active users, the first push channel can be used as the delivery channel; for target messages of non-daily active users, the second push channel can be used as the delivery channel.The message delivery rate of the second push channel is higher than that of the first push channel. Delivery rate refers to the success rate of sending push messages to the user's device. For daily active users (DAU), the first push channel will be used to send target push messages, combined with high-quality push messages selected based on preset conditions to improve user experience. For non-DAU users, to maximize the chances of every user becoming a DAU, the second push channel with a higher delivery rate will be used to try and increase the user's push delivery rate, aiming to get the user to click on the push message and become a DAU on the same day. Preferably, the first push channel can be a self-built channel, and the second push channel can be a vendor channel. A self-built channel is a push message delivery channel developed by the application provider; a vendor channel is a push message delivery channel provided by the manufacturer of the device used by the user. Both self-built and vendor channels are channels for writing push messages to the user's device; the main difference lies in the delivery rate, i.e., the success rate of sending push messages to the user's device. Because device manufacturers typically limit the activity of other client applications running on user devices and restrict the reach of push messages from self-built channels based on client applications, in order to prevent users from continuously receiving pushes and affecting their user experience, self-built channels can only reach users when the client application is active. In contrast, manufacturer channels are not limited by the activity of client applications. Self-built channels have a more lenient limit on the number of push messages that can be sent, but the reach rate is low. Manufacturer channels have a strict limit on the number of push messages that can be sent, but the reach rate is high. When sending a target push message, the user's relevant information is first obtained. Then, the push message is sent to the target user based on this user information. To send the target push message, it's necessary to obtain the target user's relevant information, including but not limited to device information, operating system, active time range, operation frequency, gender, and version information. The target push message can be sent to the target user by the push notification device based on the user's relevant information, or the push notification device can send the target push message to a downstream module. The downstream module can then send the target push message to the target user based on the user's relevant information. In this case, the user's relevant information can be appended to the target push message, and the target push message with appended user information is sent to the downstream module responsible for ultimately sending the target push message to the target user. The downstream module responsible for ultimately sending the target push message sends the target push message in a manner and time suitable for the user's device, based on the user's relevant information. Specifically, the user's relevant information can be pre-stored in HDFS in Parquet format; the user's relevant information stored in HDFS can be read using Flink file streams to improve the efficiency of obtaining user information.Traditional databases like Redis and HBase experience I / O bottlenecks when reading user features during peak periods, impacting program delivery efficiency and even causing abnormal program termination. To address this, user feature storage was migrated from the database to HDFS Parquet. Flink readFile + FileProcess-PROCESS_CONTINUOUSLY mode reads the Parquet file as a FlinkDataStream. readFile reads the Parquet file as a DataSet, enabling fast reading and caching of user features. The FileProcess-PROCESS_CONTINUOUSLY mode converts the read DataSet into a DataStream, ensuring the integrity of the streaming process and allowing the program to correctly store checkpoints for rapid recovery in case of failures. The mixed delivery refers to combining various pending messages collected from different business units within the user's corresponding push time window, regardless of source, and selectively choosing one or more messages as the target push message based on preset conditions or sending them in a certain order.

[0072] Further, determining whether the target user is a daily active user based on the periodically updated list of all daily active users includes:

[0073] Use a Bloom filter to check whether the target user is recorded in the full list of daily active users;

[0074] If the target user is found to be recorded in the full list of daily active users, the target user is determined to be a daily active user.

[0075] If the target user is not recorded in the full list of daily active users, it is determined that the target user is not a daily active user.

[0076] In some embodiments, since there are a huge number of users in the system, retrieving target users from the huge number of users will consume a lot of computing time. In order to improve efficiency, using a Bloom filter to process the full daily active user list and retrieve target users can significantly reduce the storage space occupied by the full daily active user list and significantly improve retrieval efficiency.

[0077] Further, sending the target push message to the target user includes:

[0078] The user-related information of the target user stored in HDFS is read using Flink file streams; wherein, the user-related information of each user is pre-stored in HDFS in Parquet format;

[0079] The target push message is sent to the target user corresponding to the read user-related information.

[0080] In some embodiments, when sending a target push message, the user-related information of the target user is first obtained; then, the push message is sent to the target user based on the user-related information. To send the target push message to the target user, it is necessary to obtain the target user's user-related information, which includes, but is not limited to, device information, operating system, active time range, operation frequency, gender, and version information. The target push message can be sent to the target user by a message push device based on the user-related information, or the message push device can send the target push message to a downstream module. The downstream module can then send the target push message to the target user based on the user-related information. In this case, the user-related information can be appended to the target push message, and the target push message with appended user-related information is sent to the downstream module responsible for ultimately sending the target push message to the target user. The downstream module responsible for ultimately sending the target push message sends the target push message in a manner and time suitable for the user's device based on the user-related information. Specifically, the user-related information of the target user can be pre-stored in HDFS in Parquet format; the user-related information stored in HDFS can be read through Flink file streams to improve the efficiency of obtaining user-related information. Traditional databases like Redis and HBase experience I / O bottlenecks when reading user characteristics (equivalent to user-related information) during peak periods, affecting program deployment efficiency and even causing abnormal program exits. To address this, user characteristic storage was migrated from the database to HDFS Parquet. Flink readFile + FileProcess-PROCESS_CONTINUOUSLY mode was used to read the Parquet file as a FlinkDataStream. readFile reads the Parquet file as a DataSet, enabling fast reading and caching of user characteristics. The FileProcess-PROCESS_CONTINUOUSLY mode converts the read DataSet into a DataStream, ensuring the integrity of the streaming process and allowing the program to correctly store checkpoints, enabling rapid recovery in case of failure.

[0081] Secondly, such as Figure 2 As shown, an embodiment of the present invention provides a message push device, including:

[0082] The message receiving unit 20 is used to determine whether the target user has a push time window when it receives a message to be sent to the target user;

[0083] The time window creation unit 21 is used to create a push time window corresponding to the target user, starting from the time point when the message to be pushed is received, if it is determined that the target user does not have a push time window.

[0084] The push message collection unit 22 is used to add all push messages received within the push time window and sent to the target user to the push message set corresponding to the push time window;

[0085] The push message sending unit 23 is used to select a message to be pushed that meets preset conditions from the push message set as the target push message when the push time window ends, and send the target push message to the target user.

[0086] Furthermore, the message to be pushed is sent to the target user by a business party, and the business party includes multiple parties; the message to be pushed includes slow push messages and / or direct push messages sent to the target user by the business party, wherein the slow push messages are received through a configured slow message channel, and the direct push messages are received through a configured direct message channel.

[0087] Furthermore, the push message sending unit 23 includes:

[0088] The first target push message selection module is used to select push messages with a predicted click-through rate greater than or equal to a preset click-through rate threshold as target push messages based on the predicted click-through rate corresponding to each push message in the push message set; or, select a set number of push messages with the highest predicted click-through rate as target push messages.

[0089] Furthermore, the push message sending unit 23 includes:

[0090] The first daily active user determination module is used to determine whether the target user is a daily active user based on a periodically updated list of all daily active users; wherein, the daily active user refers to a user who has active operations on the current day;

[0091] The first sending module is used to, when it is determined that the target user is a daily active user, mix the target push message and send it to the target user through the first push channel;

[0092] The second sending module is used to send the target push message to the target user through the second push channel after mixing the target push messages if it is determined that the target user is not a daily active user.

[0093] The message reach rate of the second push channel is greater than that of the first push channel.

[0094] Furthermore, the first daily active user determination module includes:

[0095] The retrieval module is used to retrieve whether the target user is recorded in the full list of daily active users using a Bloom filter;

[0096] The second daily active user determination module is used to determine that the target user is a daily active user if the target user is found to be recorded in the full list of daily active users; and to determine that the target user is not a daily active user if the target user is not found to be recorded in the full list of daily active users.

[0097] Furthermore, the push message sending unit 23 includes:

[0098] The user information acquisition module is used to read the user-related information of the target user stored in HDFS via Flink file stream; wherein, the user-related information of each user is pre-stored in HDFS in Parquet format;

[0099] The push message sending module is used to send the target push message to the target user corresponding to the read user-related information.

[0100] The message push device provided in this embodiment of the invention is a product-type embodiment corresponding to the aforementioned message push method. The embodiments of the invention can be understood based on the aforementioned message push method embodiments, and will not be repeated here.

[0101] The embodiments of the present invention have the following technical effects: by opening a push time window for a user, collecting push messages received for that user within the push time window, and selecting the best push messages from the collected push messages to send to the user at the end of the push time window, the real-time performance is improved compared to offline push, and the content quality of push messages is improved compared to direct push, thereby balancing timeliness and content quality to improve the user experience.

[0102] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method as described in any one of the first aspects.

[0103] The readable storage medium provided in this embodiment of the invention is used to store program code corresponding to any of the methods described in the first aspect. The embodiments of the invention can be understood based on the foregoing embodiments of the message push method, and will not be repeated here.

[0104] The embodiments of the present invention have the following technical effects: by opening a push time window for a user, collecting push messages received for that user within the push time window, and selecting the best push messages from the collected push messages to send to the user at the end of the push time window, the real-time performance is improved compared to offline push, and the content quality of push messages is improved compared to direct push, thereby balancing timeliness and content quality to improve the user experience.

[0105] The technical solutions of the present invention will be described in detail below with reference to specific application examples. For technical details not described in the implementation process, please refer to the relevant descriptions above.

[0106] Spark is a fast, versatile, and scalable big data analytics engine;

[0107] push means message push;

[0108] Flink, or Apache Flink, is an open-source stream processing framework developed by the Apache Software Foundation. Its core is a distributed streaming data stream engine written in Java and Scala.

[0109] In the technical solution of this invention, uid-mid represents a pair of user ID (i.e., uid) and message ID (i.e., mid);

[0110] DAU stands for Daily Active Users, which represents daily active users.

[0111] QPS stands for Queries per second;

[0112] Parquet: Stores large amounts of user characteristics on a commonly used big data HDFS cluster;

[0113] readFile: Reads a file as a DataSet, allowing the reading of user characteristics to avoid real-time database access and reducing IO wait time;

[0114] FileProcess-PROCESS_CONTINUOUSLY: Converts a DataSet to a DataStream. Only in the DataStream state can the program store checkpoints correctly, ensuring that the program can recover quickly in the event of a failure.

[0115] In existing technologies, offline computation and push notifications are mainly performed using Spark. Offline tasks are cumbersome and resource-intensive, taking only one hour to cover all users, resulting in low timeliness of delivery to users. Direct push notifications deliver to users with high timeliness, but the effect is uncontrollable, and the quality of materials can only be judged based on some prior experience. The inventors discovered that a new type of push notification is needed that can guarantee both timeliness and delivery effectiveness, thus extending and supplementing both approaches to a certain extent.

[0116] Offline SparkPush (equivalent to offline mixed ordering) matches user materials through algorithm packages and calculates all users every hour. It is accurate but lacks timeliness. Direct push directly sends pushes to targeted users through simple rules. It is timely but the effect is uncontrollable. Combining the advantages and disadvantages of the two types of push, real-time mixed ordering switches the above Spark batch processing method to Flink stream processing. It writes the uid-mid of offline push (equivalent to slow push message) and direct push (equivalent to direct push message) into real-time mixed ordering (equivalent to the message push device of this application). When a user receives the first uid-mid sent by the business party, a 10-minute time window (i.e., push time window) is opened for the current user. The uid-mid sent by other business parties for the same uid within the next 10 minutes will be collected in the same 10-minute time window. When the 10-minute time expires, the best uid-mid received by a single user within 10 minutes is sent out. The implementation of the 10-minute window ensures that the user delivery cycle is shortened from 1 hour to 10 minutes, greatly improving timeliness. At the same time, by selecting the best uid-mid from multiple uid-mid collected within 10 minutes for delivery, the problem of uncontrollable material quality caused by direct push delivery is avoided.

[0117] A: Context Acquisition: Since auxiliary decision variables such as user DAU are updated in real time, a context data stream is needed to periodically update the DAU status of all users. DAU is recorded in real time by the cluster Redis for users who click push. Here, the latest full DAU data is read from Redis every 5 minutes. Since the number of push users is in the tens of millions, a Bloom filter is used instead of the full user set, saving ten times more memory. With the lightweight DAU Bloom filter, the downstream can also adjust the push delivery strategy and channel in real time based on the user's DAU status to optimize the reach rate and content of different types of users.

[0118] B: File Stream: This involves using `readFile` + `FileProcess` - `PROCESS_CONTINUOUSLY` to read user data as a Flink data stream. User deployment requires retrieving various user information such as device version and channel. Reading from HBase or Redis is inefficient and impacts program execution. This innovative approach uses a file stream to incorporate offline cached user features into the real-time program, achieving rapid loading of all user features. The file stream implements Flink's batch conversion, transforming static Parquet file data into a DataStream required for Flink streaming processing. The original method of accessing the database using HBase and Redis to obtain user characteristics resulted in severe network I / O pressure during peak push periods. Peak push business saw instantaneous QPS reaching millions, causing short-term slow database responses and impacting push delivery timeliness. In severe cases, this could lead to program failure and disrupt the stable operation of online services. By caching large amounts of user data in offline Parquet files and reading them all at once upon program startup, user characteristics can be quickly cached (within 2 minutes). This completely eliminates the dependence of user data on the database, ensuring that tasks are unaffected by network I / O during peak push periods, significantly improving program timeliness and stability. Furthermore, to ensure proper storage of task checkpoints, the FileProcess-PROCESS_CONTINUOUSLY parameter was added to file reading, enabling the program's fault recovery module to function normally, achieving high concurrency and high availability.

[0119] like Figure 3 As shown, the database solution using Redis+HBase is affected by network I / O, resulting in bottlenecks in throughput during peak periods, and the output data is nearly parallel. Figure 4 As shown, after modifying to a file stream, the output data is in camelCase, saving half the time compared to before, greatly improving the distribution efficiency, and increasing the timeliness and click volume of the materials.

[0120] C: KafkaSource, which is the Kafka data source, receives user uid-mid pairs from offline pushes (i.e., SparkPush). Offline pushes involve a large number of users, so Kafka is used to achieve high throughput.

[0121] D: RedisSource, i.e., Redis data source, receives user uid-mid pairs directly sent by push. Since the push is mainly based on rules and user targeting, and mostly consists of hot-topic materials, there is a lot of common content. Therefore, it is written to the Redis queue in a one-to-many form of mid-uids [maximum 1000], and the Flink program is responsible for consuming it.

[0122] E: Merged Stream. This stream simultaneously accepts four data sources: A, B, C, and D. It implements a 10-minute window for each UID based on its granularity. Stream A determines the user's status, stream B reads the features required for user delivery, stream C reads the user's offline push-mid pair, and stream D reads mid-uid pairs, processing the mid values ​​separately within the 10-minute windows for each UID. This completes the preparation for user delivery, accepting uid-mid pairs from multiple service providers within a 10-minute window and saving the user delivery information.

[0123] F: The delivery stream is based on a 10-minute window for each user in the E stream. When the 10-minute window expires, the top 1 of the uid-mid pairs from multiple service providers is selected, and user information and status are combined until delivery.

[0124] The entire process of real-time mixed sorting for users is realized through a multi-segment flow of [A+B+C+D]->E->F.

[0125] [A+B+C+D] represents all information sources, E represents the user window aggregation and selection phase, and F represents the user distribution phase.

[0126] The technical solution of this invention has the following technical effects:

[0127] 1. Timeliness: FlinkTimeWindow implements a 10-minute window at the UID granularity, ensuring that UID-mid pairs within a 10-minute period are aggregated and optimally delivered. Compared to the hourly latency of offline push, this significantly improves the timeliness of materials reaching users. Many timely and high-quality Weibo posts have also achieved faster delivery to users, increasing the overall user engagement. Taking the "Special Attention" post #10000752 as an example, single-business delivery PV increased by 39.67%, click PV increased by 57.08%, and click-through rate increased by 12.46%. This demonstrates that improved timeliness has a significant impact on the reach and click-through rate of high-quality materials.

[0128] 2. Performance Guarantee and User Experience: Direct push notifications are fast and consume users' daily push quota, but their quality is uncontrollable. By classifying direct push notifications, high-priority materials, such as full-scale hot topics, will continue to be sent via direct push without entering real-time mixed ranking. Direct push notifications with relatively unstable performance (mainly based on historical click-through rates) will be included in real-time mixed ranking. This ensures delivery quality while sacrificing some timeliness, and also prevents users from quickly exhausting their push quota. This reduces the number of users opening the notifications and improves the user experience, decreasing the proportion of users closing the notification.

[0129] 3. Lightweight, high throughput and high availability: By replacing the Spark framework with Flink, lightweight applications are achieved and high throughput is realized. At the same time, the introduction of Flink checkpoints improves the robustness of tasks, making tasks efficient, stable and effective.

[0130] 4. Real-time Mixed Ranking Mechanism: Combining the advantages of traditional offline push and direct push, a 10-minute real-time mixed ranking mechanism is introduced, which improves the timeliness of push while ensuring higher quality of pushed materials.

[0131] 5. Using file streams instead of sockets to read user characteristics: Traditional databases like Redis and HBase experience IO bottlenecks when reading user characteristics during peak periods, affecting program deployment efficiency and even causing abnormal program exits. To address this, user characteristic storage is migrated from the database to HDFS Parquet. Flink readFile + FileProcess-PROCESS_CONTINUOUSLY is used to read the data as a FlinkDataStream. readFile reads the Parquet file as a DataSet, enabling fast reading and caching of user characteristics. The FileProcess-PROCESS_CONTINUOUSLY mode converts the read DataSet into a DataStream, ensuring the integrity of the streaming program and allowing the program to correctly store checkpoints for rapid recovery in case of failure.

[0132] It should be understood that the specific order or hierarchy of steps in the disclosed process is an example of an exemplary method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process may be rearranged without departing from the scope of this disclosure. The appended method claims provide elements of various steps in an exemplary order and are not intended to limit the scope to the specific order or hierarchy described.

[0133] In the above detailed description, various features are combined together in a single embodiment to simplify this disclosure. This approach to disclosure should not be construed as reflecting an intention that embodiments of the claimed subject matter require more features than are explicitly stated in each claim. Rather, as reflected in the appended claims, the invention is presented with fewer features than all of the features of the single disclosed embodiment. Therefore, the appended claims are hereby explicitly incorporated into the detailed description, wherein each claim stands alone as a preferred embodiment of the invention.

[0134] The disclosed embodiments have been described above to enable any person skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments without departing from the spirit and scope of this disclosure. Therefore, this disclosure is not limited to the embodiments given herein, but is consistent with the broadest scope of the principles and novel features disclosed in this application.

[0135] The foregoing description includes examples of one or more embodiments. It is certainly impossible to describe all possible combinations of components or methods in order to describe the above embodiments, but those skilled in the art will recognize that further combinations and arrangements of the various embodiments are possible. Therefore, the embodiments described herein are intended to cover all such changes, modifications, and variations falling within the scope of the appended claims. Furthermore, the term "comprising" as used in the specification or claims is used in a manner similar to the term "including." Additionally, the use of any term "or" in the specification of the claims is intended to mean "non-exclusive or."

[0136] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A message push method, characterized in that, include: Upon receiving a message to be pushed to a target user, determine whether the target user is within a push time window; If it is determined that the target user does not have a push time window, a push time window corresponding to the target user is created starting from the time point when the message to be pushed is received. All messages to be pushed to the target user received within the push time window are added to the push message set corresponding to the push time window; When the push time window ends, select a message that meets the preset conditions from the push message set as the target push message, and send the target push message to the target user; The message to be pushed is sent to the target user by a business party, and the business party includes multiple parties; the message to be pushed includes slow push messages and / or direct push messages sent to the target user by the business party, wherein the slow push messages are received through a configured slow message channel, and the direct push messages are received through a configured direct message channel. The step of selecting a message that meets preset conditions from the set of push messages as the target push message includes: Based on the predicted click-through rate (CTR) of each message to be pushed in the push message set, messages to be pushed with a CTR greater than or equal to a preset CTR threshold are selected as target push messages; or, a set number of messages to be pushed with the highest predicted CTR are selected as target push messages.

2. The message push method as described in claim 1, characterized in that, Sending the target push message to the target user includes: The target user is determined to be a daily active user based on a periodically updated list of all daily active users; wherein, a daily active user refers to a user who has engaged in activity on that day. If the target user is determined to be a daily active user, the target push message is mixed and then sent to the target user through the first push channel; If it is determined that the target user is not a daily active user, the target push message will be mixed and sent to the target user through the second push channel; The message reach rate of the second push channel is greater than that of the first push channel.

3. The message push method as described in claim 2, characterized in that, The step of determining whether the target user is a daily active user based on a periodically updated list of all daily active users includes: Use a Bloom filter to check whether the target user is recorded in the full list of daily active users; If the target user is found to be recorded in the full list of daily active users, the target user is determined to be a daily active user. If the target user is not recorded in the full list of daily active users, it is determined that the target user is not a daily active user.

4. The message push method as described in claim 1, characterized in that, Sending the target push message to the target user includes: The user-related information of the target user stored in HDFS is read using Flink file streams; wherein, the user-related information of each user is pre-stored in HDFS in Parquet format; The target push message is sent to the target user corresponding to the read user-related information.

5. A message push device, characterized in that, include: The message receiving unit is used to determine whether the target user has a push time window when it receives a message to be sent to the target user; The time window creation unit is used to create a push time window corresponding to the target user, starting from the time point when the message to be pushed is received, if it is determined that the target user does not have a push time window. The push message collection unit is used to add all push messages received within the push time window and sent to the target user to the push message set corresponding to the push time window; The push message sending unit is used to select a message to be pushed that meets preset conditions from the push message set as the target push message when the push time window ends, and send the target push message to the target user. The message to be pushed is sent to the target user by a business party, and the business party includes multiple parties; the message to be pushed includes slow push messages and / or direct push messages sent to the target user by the business party, wherein the slow push messages are received through a configured slow message channel, and the direct push messages are received through a configured direct message channel. The push message sending unit includes: The first target push message selection module is used to select push messages with a predicted click-through rate greater than or equal to a preset click-through rate threshold as target push messages based on the predicted click-through rate corresponding to each push message in the push message set; or, select a set number of push messages with the highest predicted click-through rate as target push messages.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-4.

Images