Disclosure of Invention
The present disclosure provides a method for pushing a service, including:
forming a first plurality of user pairs from a first set of users;
for each user pair of the first plurality of user pairs, training a predictive model using the one or more relationship features of the user pair and the behavior labels of the two users of the user pair, the behavior labels of the users indicating whether the user has selected the service;
forming a second plurality of user pairs from a second set of users;
for each user pair of the second plurality of user pairs, predicting a probability that the user pair selects the service based on one or more relationship features of the user pair using a trained prediction model; and
selecting a set of target user pairs from the second plurality of user pairs to push the traffic based on the probability.
Optionally, the method further comprises:
pushing traffic to users in the first plurality of user pairs; and
obtaining the behavior tag of each user of the first plurality of user pairs.
Optionally, the obtaining the behavior tag comprises:
if the user selects the service, determining that the behavior tag is a first value; and
and if the user does not select the service, determining that the behavior tag is a second value.
Optionally, the forming of the first plurality of user pairs from the first set of users comprises:
for each user pair in the first set of users:
determining the relationship strength of the user pair;
comparing the relationship strength to a first threshold;
if the strength of relationship is greater than or equal to the first threshold, including the user pair in the first plurality of user pairs; and
if the strength of relationship is less than the first threshold, not including the user pair in the first plurality of user pairs.
Optionally, said forming a second plurality of user pairs from a second set of users comprises:
for each user pair in the second set of users:
determining the relationship strength of the user pair;
comparing the relationship strength to a second threshold;
if the strength of relationship is greater than or equal to the second threshold, including the user pair in the second plurality of user pairs; and
if the strength of relationship is less than the second threshold, not including the user pair in the second plurality of user pairs.
Optionally, the determining the relationship strength of the pair of users comprises:
and carrying out weighted summation on the values of one or more relation characteristics of the user pair to obtain the relation strength of the user pair.
Optionally, selecting the service comprises: clicking and/or purchasing the service.
Optionally, the training the predictive model comprises: for each user pair of the first plurality of user pairs, further training the predictive model using one or more user characteristics of two users of that user pair; and is
The prediction probability includes: for each user pair of the second plurality of user pairs, predicting, using the trained predictive model, a probability of the user pair selecting the service based further on one or more user characteristics of two users of the user pair.
Optionally, the relationship features of the user pair include device sharing data features, social relationship data features, and/or funding relationship data features of both users of the user pair.
Optionally, the selecting the set of target user pairs comprises:
ranking the probability of selecting the service by the second plurality of users; and
selecting the set of target user pairs according to the ranking.
Optionally, the selecting a plurality of target user pairs comprises:
determining, for each user pair of the second plurality of user pairs, whether a probability that the user pair selects the service is greater than a third threshold; and
and if the probability of selecting the service by the user pair is greater than a third threshold value, determining the user pair as a target user pair.
Another aspect of the present disclosure provides an apparatus for pushing traffic, including:
means for forming a first plurality of user pairs from a first set of users;
means for training, for each of the first plurality of user pairs, a predictive model using the one or more relationship features of the user pair and behavior labels of two users of the user pair, a behavior label of a user being indicative of whether the user has selected the business;
means for forming a second plurality of user pairs from a second set of users;
means for predicting, for each user pair of the second plurality of user pairs, a probability of the user pair selecting the business based on one or more relationship features of the user pair using a trained prediction model; and
means for selecting a set of target user pairs from the second plurality of user pairs to push the traffic based on the probability.
Optionally, the apparatus further comprises:
means for pushing traffic to users in the first plurality of user pairs; and
means for obtaining the behavior tag for each user of the first plurality of user pairs.
Optionally, the module for obtaining a behavior tag includes:
means for determining that the behavior tag is a first value if the user selects the service; and
means for determining that the behavior tag is a second value if the user does not select the service.
Optionally, the means for forming a first plurality of user pairs from a first set of users comprises:
means for performing the following for each pair of users in the first set of users:
determining the relationship strength of the user pair;
comparing the relationship strength to a first threshold;
if the strength of relationship is greater than or equal to the first threshold, including the user pair in the first plurality of user pairs; and
if the strength of relationship is less than the first threshold, not including the user pair in the first plurality of user pairs.
Optionally, the means for forming a second plurality of user pairs from the second set of users comprises:
means for performing the following for each pair of users in the second set of users:
determining the relationship strength of the user pair;
comparing the relationship strength to a second threshold;
if the strength of relationship is greater than or equal to the second threshold, then including the user pair in the second plurality of user pairs; and
if the strength of relationship is less than the second threshold, not including the user pair in the second plurality of user pairs.
Optionally, the module for determining the relationship strength of the pair of users comprises:
and means for weighted summing the values of the one or more relationship features of the user pair to obtain a relationship strength of the user pair.
Optionally, selecting the service comprises: clicking and/or purchasing the service.
Optionally, the means for training the predictive model comprises: for each user pair of the first plurality of user pairs, further training the predictive model using one or more user features of two users of that user pair; and is
The means for predicting the probability comprises: means for predicting, for each user pair of the second plurality of user pairs, a probability of the user pair selecting the service based further on one or more user characteristics of two users of the user pair using a trained predictive model.
Optionally, the relationship features of the user pair include device sharing data features, social relationship data features, and/or funding relationship data features of both users of the user pair.
Optionally, the means for selecting a set of target user pairs comprises:
means for ranking the probability of selecting the service by the second plurality of users; and
means for selecting the set of target user pairs according to the ranking.
Optionally, the means for selecting a plurality of target user pairs comprises:
means for determining, for each user pair of the second plurality of user pairs, whether the probability that the user pair selects the service is greater than a third threshold; and
and determining the user pair as a target user pair if the probability that the user pair selects the service is greater than a third threshold.
One aspect of the present disclosure provides an apparatus for pushing a service, including:
a processor; and
a memory arranged to store computer executable instructions that, when executed, cause the processor to:
forming a first plurality of user pairs from a first set of users;
for each user pair of the first plurality of user pairs, training a predictive model using the one or more relationship features of the user pair and the behavior labels of the two users of the user pair, the behavior labels of the users indicating whether the user has selected the service;
forming a second plurality of user pairs from a second set of users;
for each user pair of the second plurality of user pairs, predicting a probability that the user pair selects the service based on one or more relationship features of the user pair using a trained prediction model; and
selecting a set of target user pairs from the second plurality of user pairs to push the traffic based on the probability.
Detailed Description
In order to make the aforementioned objects, features and advantages of the present disclosure comprehensible, embodiments accompanied with figures are described in detail below.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure, but the present disclosure may be practiced in other ways than those described herein, and thus the present disclosure is not limited to the specific embodiments disclosed below.
Conventionally, in service push, the probability that a user will click on/purchase a certain service can be predicted according to user characteristic data of the user (for example, the user's age, constellation, academic calendar, region, income, and the like), but the prediction of the click on/purchase rate of the interactive service by the user characteristic data is not accurate enough.
Interactive class services are a recently emerging form of services that may involve interactive operations between two or more users, such as close payments, security guards, and the like. Close payment may allow payment to be made using one account for another account, e.g., shopping payment, money transfer, etc. The security daemon can define two associated accounts as a daemon account and a protected account respectively, and if the protected account has an abnormal condition, an alarm can be sent to the daemon account.
Interactive class services often involve relationship data between multiple users. For example, the relationship between users of two associated accounts of close payment and security guard is often a family member (e.g., spouse, parent, child, etc.) or close friend. Therefore, when the interactive service is pushed to the users, the accuracy of click/purchase rate prediction can be improved by taking the relation between two or more users into consideration.
The present disclosure considers the above characteristics of interactive services, and uses the user-pair relationship characteristics in the process of predicting the click/purchase probability of a service in order to make up for the deficiency of individual user characteristics. A user-pair relationship feature is a feature that characterizes the relationship between two users (user pairs).
For example, user-to-relationship features may include the following three categories:
an intermediary relationship feature, which may include common data (e.g., number of times of sharing, duration of sharing, etc.) of two users with respect to an intermediary (e.g., device, gateway, phone number, mailbox, etc.);
second, the social relationship characteristics may include mobile phone/phone call information of two users, operation information (e.g., adding friends, chatting times, forwarding times, comment times) of social software (e.g., wanbao wang, WeChat, microblog, etc.), and the like;
and thirdly, a fund relationship characteristic, which can comprise payment generation and transfer data (such as times, amount and the like) between two users.
A few examples of the relationship features of user pairs are listed above, but those skilled in the art will appreciate that the relationship features of user pairs are not limited to the above examples only, as long as data capable of reflecting closeness of relationship between different users is within the contemplation of the present disclosure.
Further, users tend to operate using accounts, and thus the terms "user" and "account" are used interchangeably herein.
Fig. 1 is a diagram of a system 100 for pushing traffic based on user relationships, in accordance with various aspects of the present disclosure.
As shown in FIG. 1, the system 100 may include a plurality of terminals 1011-N, a server 102, and a database 103. The plurality of terminals 101-1-N, the server 102 and the database 103 may communicate via a wired or wireless connection.
The terminal 101 may be a device having a network connection function, such as a smart phone, a notebook computer, a tablet computer, a desktop computer, and the like. An application (e.g., pay-for-your-details, WeChat, etc.) may be running on the terminal 101.
The server 102 may be a single server or a server cluster including a plurality of servers. The server 102 may provide various business services to the plurality of terminals 101-1-N.
Each terminal 101 may perform various operations, including interactive operations, through the server 102. For example, these operations may include sending mail, voice calls, chatting using apps, transfers between accounts, account surcharges, and so forth.
Further, the server 102 may collect data from the respective terminals 101, such as a relationship characteristic between two users (user pairs) (a relationship characteristic of a user pair, simply referred to as a relationship characteristic) and/or an individual characteristic of a user (referred to herein as a user characteristic). For example, the server 102 may collect the relationship features and the user features in an operation log and/or an operation message (e.g., an operation request) of the terminal 101.
The relationship features may include media relationship features, social relationship features, and funding relationship features as described above. User characteristics may include the user's own age, constellation, academic calendar, income, historical behavior, and so forth.
Server 102 may store the collected relational features and user features in database 103 for subsequent use. Database 103 may store behavior tag data for users, relationship characteristics for pairs of users, and optionally user characteristics.
Server 102 further may include a predictive model (e.g., a supervised model) for predicting a probability of a user selecting a service. Server 102 may train the supervised model using a training set, which may include behavioral labels of users in a set of users (including a plurality of user pairs) (representing whether a user selected a business, e.g., whether to click on, purchase a business), and relationship features and optional user features of the plurality of user pairs to train the supervised model; the trained supervised model may then be used to predict behavioral data for other users, such as the probability of a user selecting (clicking on or purchasing) a service.
Note that although in fig. 1, the server 102 and the database 103 are shown separately, the database 103 may be incorporated into the server 102.
FIG. 2 is a diagram of user pair relationships in a user set that includes four users (i.e., users 1-4).
The user-pair relationship in the set of users may include a relationship between any two users in the set of users. As depicted in FIG. 2, a user-pair relationship comprising a user set of user 1, user 2, user 3, and user 4 may comprise: relationships between user pair 12 (user 1 and user 2), user pair 13 (user 1 and user 3), user pair 14 (user 1 and user 4), user pair 23 (user 2 and user 3), user pair 24 (user 2 and user 4), and user pair 34 (user 3 and user 4).
The set of users comprising n users may comprise
A pair of users.
The relational characteristics of a user pair may be stored in database 103 using the identification of both users as an index. Table 1 shows one example of a storage structure for user pair characteristics for a user set comprising n users, where the identity of each user is represented by the numbers 1-n. Those skilled in the art will appreciate that other ways of identifying user pairs are also contemplated by the present disclosure. Each user-pair relationship may have one or more relationship characteristics.
TABLE 1
The user-pair relationship characteristics may include common data (e.g., number of times of sharing, length of time of sharing) for the device, gateway, phone number, mailbox, of the two users; the two users add friend behaviors, chatting times, forwarding times, comment times and the like to the social software; data on the exchange of funds between two users, such as a payment by a representative, the number of transfers, the amount of money, etc.
FIG. 3 is a diagram of a method of pushing traffic based on user-to-relationship features in accordance with aspects of the present disclosure.
In the method of pushing a service based on the user-to-relationship feature of the present disclosure, the server 102 first puts the service on a small scale, for example, randomly puts the service to a subset of related users (shown as a first user set in fig. 3, for example, hundreds or thousands of users), and acquires a behavior tag of each user in the user subset, where the behavior tag indicates whether the user selects the service, for example, whether to click the service, whether to purchase the service, and the like. Server 102 may then retrieve the user-pair relationship features (and optional user features) for the subset of users from database 103 and train the supervised model using the retrieved relationship features (and optional user features) and the behavioral labels of the users. After training the supervised model, server 102 may use the trained supervised model to predict behavioral data for the user pair (probability of the user pair selecting a service, e.g., probability of clicking on the service, probability of purchasing the service).
The behavior labels for training the supervised model are of the same type as the behavior data predicted using the supervised model. For example, if the system is to predict the probability of the user in the second user set clicking on the service, the behavior tag obtained by the server 102 may be whether the user in the first user set has clicked on the service; if the system is to predict the probability of a user in the second set of users purchasing the service, the server 102 obtains an action tag as to whether the user in the first set of users purchases the service, and so on.
In the following description, behavior tags and behavior data are illustrated for purchase traffic, but those skilled in the art will appreciate that other types of behavior tags and behavior data are also contemplated by the present disclosure.
As shown in fig. 3, the server 102 may push traffic to users in the first set of users in step 301.
The first set of users may be a subset of a set of related users of the service (e.g., a set of potential users to purchase the service). The server 102 may randomly select a subset of relevant user combinations of the service as the first set of users. Further, the server 102 may form a first plurality of user pairs from the first set of users and push traffic to the first plurality of user pairs.
In particular, the
server 102 may form one user pair two by two for the users in the first set of users, thereby forming a first plurality of user pairs, e.g., as shown in the example in fig. 2. A first set of n users may form
A pair of users.
Optionally, the server 102 may filter out a plurality of user pairs with a higher strength of relationship (e.g., higher than a threshold) from all user pairs in the first user set as the first plurality of user pairs for traffic pushing.
For example, for each user pair formed in the first set of users, the values of the plurality of relationship features of the user pair may be weighted and summed to determine their relationship strength S. If the strength of relationship S is above a threshold (a first strength threshold), the user pair may be included in a first plurality of user pairs to push traffic for subsequent model training operations; if the relationship strength S is below the first strength threshold, the user pair may not be included in the first plurality of user pairs.
If the strength of the relationship of the user pair is low, the relationship of the two users of the user pair is not tight enough, and the reference significance for the data prediction of the interactive service is not large.
The calculation amount of the training model can be reduced by screening the first plurality of user pairs through the user intensity, and communication resources of service push are saved.
At step 302, the server 102 may obtain a behavior tag for each user of the first plurality of user pairs with respect to the service.
The user's behavior tag may characterize whether the user selects (e.g., clicks on or purchases) the service.
For example, if a user purchases the service, server 102 may determine that the user's behavior tag is a first value (e.g., 1); if the user does not purchase the service, server 102 may determine that the user's behavior tag is a second value (e.g., 0). The values here are merely examples, and other values are possible.
After the server 102 obtains the behavior tags of the users, they may be stored in the database 103 for later use.
Server 102 may retrieve the relationship characteristics of the first plurality of user pairs from database 103 at step 303.
For each user pair of the first plurality of user pairs, the server 102 may look up in the database 103 one or more relationship characteristics of the user pair that are relevant to the service, and one or more user characteristics of each of the two users of the user pair.
The user-pair relationship characteristics may include data common to both users (e.g., number of shares, duration of shares) for the device, gateway, phone number; the two users add friend behaviors, chatting times, forwarding times, comment times and the like to the social software; data on the exchange of funds between two users, e.g. number of payments, transfers, amount, etc.
The user characteristics may include the user's age, gender, constellation, location, membership information, historical behavior tags (e.g., historical click-through rates, conversion rates, etc. with respect to related services), and so forth.
Although steps 301 and 302 precede step 303 in fig. 3, step 303 may also be performed before step 301 or 302.
Server 102 may also obtain user characteristics of users in the first plurality of user pairs for subsequent model training.
At step 304, server 102 may train a predictive model using the behavior labels of the users in the first plurality of user pairs obtained at step 302 and the relationship features of the user pairs obtained at step 303.
Preferably, the server 102 may further train the model using user characteristics of users in the first plurality of user pairs.
The server 102 may select the relationship features of the user pairs, and optionally the user features, based on the characteristics of the service, quantize them and form a feature vector. Server 102 may train the model using the feature vectors and the behavior labels of the two users of the pair as inputs.
For example, close payment typically involves two of the family members. In this case, the user-to-relationship feature may include the number and/or duration of times the gateways, computer devices are shared by the accounts of the two users, since family members tend to log on to the account at home using the same gateway or using the same computer device; the user pair relation characteristics can also comprise the chatting times and transfer records (transfer times and money amount) of the accounts of the two users on the chatting software; the user-to-relationship feature further may include information that the accounts of the two users share a phone number or mailbox, e.g., the two accounts may be registered with the same phone number or mailbox on the platform (e.g., paypal, wechat).
Preferably, the close payment may also relate to the user characteristics of the user himself, e.g. the age, sex, territory, etc. of the two users each. For example, if the two users are sexually male and female, respectively, and are closely related in age (e.g., less than ten years old), then the probability of the two users being a spouse is greater; if the ages of two users are twenty to thirty years old, the relationship between the two users may be a relationship between a parent and a child, and the probability of using close payment is high. As another example, the user characteristics may also include a payment ability, if the payment ability of both users is low, the probability of using close payment is low; the probability of close payment being used is higher if the payment capacity of at least one of the two users is higher. As yet another example, the user characteristics may further include account liveness of both users, e.g., if account liveness of both users is high (e.g., the number of active days is long), then the probability of using affinity payment is also high.
The example of the user-to-relationship feature and the user feature is described above by taking the close-up payment as an example, but the relationship feature and the user feature of the present disclosure are not limited thereto. Those skilled in the art will appreciate that other relationship and user characteristics may also be used, and that different services may consider different relationship and user characteristics.
For each pair of users in the first set of users, the server 102 may train the supervised model by forming a feature vector using the relationship features and optionally the user features of the pair, and inputting the feature vector and the behavior labels of the two users into the supervised model.
For example, a feature vector of a user pair comprising user i and user j may be expressed as:
f ij =[P 1 ,P 2 ,…,P a ,I 1 ,I 2 ,…,I b ,J 1 ,J 2 ,…,J c ,],
wherein P is 1 ,P 2 ,…,P a Is a relational characteristic value, I 1 ,I 2 ,…,I b Is a user characteristic value of user i, J 1 ,J 2 ,…,J c The user characteristic value of the user j.
As an example, if the relationship characteristics of a user pair include P 1 Number of chats (159), P 2 Common computer duration (512 (hours)), P 3 Transfer amount (15600 (yuan)); the user characteristics of user I include I 1 Gender (1/woman), I 2 Age (30), user characteristics of user J include J 1 Gender (0/man), J 2 Age (35), then the feature vector f ij =[159,512,15600,1,30,0,30]。
The server 102 inputs the feature vectors of the user pairs into the supervised model for training, along with the behavior labels of the two users in the user pairs.
For example, the input to the model may be { f } ij ,L i ,L j }。
Wherein L is i Is a behavior tag for user i, and L j Is the behavior tag of user j. For example, if user i purchases a service, L i May be 1, if user i does not purchase the service, L i May be 0; if user j purchases the service, L j May be 1, if user j does not purchase the service, L j May be 0.
The above examples use relational features and user features to train the model, but the model may also be trained using only relational features.
At step 305, server 102 obtains from database 103 the relationship characteristics of the user pairs of the second plurality of user pairs in the second set of users.
The second set of users may be a set of related users of the service. The server 102 may predict behavior data of each user in the second set of users and select a target set of users from the second set of users to push traffic based on the behavior data.
The server 102 may form pairs of users in the second set of users into a user pair, thereby forming a second plurality of user pairs.
Optionally, the server 102 may filter out a plurality of user pairs with a higher strength of relationship (e.g., above a second strength threshold) among all user pairs in the second set of users as the second plurality of user pairs.
For example, for each user pair formed in the second set of users, the values of the plurality of relationship features of the user pair may be weighted and summed to determine their relationship strength S. If the strength of relationship S is above a second strength threshold, the user pair may be included in a second plurality of user pairs for subsequent predictive operation; if the relationship strength S is below a second strength threshold, the user pair may not be included in the second plurality of user pairs.
For example, if a user pair comprising user i and user j has a relational feature value P 1 ,P 2 ,…,P a Then the strength of the relationship for the pair of users can be calculated as follows:
S=ω 1 P 1 +ω 2 P 2 +…+ω a P a 。
wherein 0 is not less than omega i ≤1,ω i The value of (c) can be selected according to the actual needs.
If the relation strength S is lower than a threshold value, which indicates that the relation between the two users is not close enough and the interactive service is unlikely to be purchased, the two users in the user pair can be removed from the relevant user set without performing subsequent prediction operation. In other words, the server 102 may only include two users in the user pair with the relationship strength S higher than the threshold value in the relevant user set into the second user set, so that the calculation amount of the model prediction may be reduced.
At step 306, server 102 uses the relationship characteristics of the second plurality of user pairs obtained at step 305 to predict behavioral data of the user pairs with respect to the business.
In particular, for each user pair, e.g., user pair i-j including user i and user j, the relationship features of user pair i-j may be input into a trained predictive model to predict the probability that user pair i-j will purchase/click traffic.
Optionally, the user characteristics of user i and the user characteristics of user j may also be input into the trained model together with the relationship characteristics for prediction.
The relational features and optional user features included in the input to the predictive model in step 306 may correspond to the relational features and optional user features included in the input to the training model in step 304.
At step 307, the server 102 may determine a set of target user pairs in the second set of users.
For example, server 102 may sort the behavioral data of the user pairs, selecting the top ranked user pair as the target user pair.
As another example, server 102 may also set a threshold value that determines a user pair as a target user pair if the predicted behavior data for the user pair is above.
In step 308, the server 102 may push traffic to the users in the set of targeted user pairs.
Note that it is described in the above embodiment that the user pair relationship features and the user features are acquired to train the model and the predicted behavior data in steps 303 and 305, but it is also possible to train the model and the predicted behavior data using only the user pair relationship features without using the user features.
FIG. 4 is a flow diagram of a method of pushing traffic based on user-pair relationships, in accordance with aspects of the present disclosure.
At step 402, a first plurality of user pairs may be formed from a first set of users.
The first set of users may be a subset of a set of related users of the service (e.g., a set of potential users to purchase the service). The relational features of the first plurality of user pairs and the behavior tags indicating whether users in the first plurality of user pairs select a business may be used to train the model.
In an aspect, all users in the first set of users may be paired into user pairs as the first plurality of user pairs.
In another aspect, all user pairs in the first set of users may be filtered to form a first plurality of user pairs based on their strength of relationship. For example, the values of a plurality of relationship features of a user pair may be weighted and summed to determine a relationship strength S for the user pair. If the strength of relationship S is below a first strength threshold, the user pair may be culled from the first plurality of user pairs without subsequent model training.
At step 404, the model may be trained using the relational features and the behavior labels of the first plurality of user pairs.
In particular, a service may be pushed to a user of a first plurality of user pairs, followed by obtaining a behavior tag for each user, the behavior tag characterizing whether the user selects the service, e.g. whether to click or purchase the service.
The relationship characteristics of the user pairs may include common data characteristics of the two users with respect to the medium (e.g., common data (e.g., number of times of sharing, length of time of sharing) of the two users with respect to the device, gateway, telephone number); social relationship data characteristics of the two users (e.g., behavior of the two users adding friends to each other on social software, number of chats, number of forwards, number of reviews, etc.); a financial relationship characteristic (e.g., data on the exchange of funds between two users, such as a payment by date, the number of transfers, the amount, etc.).
The predictive model may be trained using the relational features and the behavior labels of the first plurality of user pairs.
At step 406, a second plurality of user pairs may be formed from the second set of users.
The second set of users may be a set of related users of the service.
In an aspect, the second plurality of user pairs may be formed by pairwise forming of users in a set of related users of the service into user pairs.
In another aspect, all user pairs in the second set of users may be filtered to form a second plurality of user pairs based on the strength of relationship of the user pairs. For example, a plurality of relationship features of a user pair may be weighted and summed to determine a relationship strength S for the user pair. If the strength of relationship S is below a second strength threshold, the user pair may be culled from the second plurality of user pairs without subsequent prediction operations.
At step 408, a probability of the user pair selecting a service may be predicted based on the relationship features of the second plurality of user pairs using the trained predictive model.
For example, for a user pair ij comprising user i and user j, the relationship features of the user pair ij can be input into a trained model to predict the probability that the user pair ij selects a service (e.g., the probability that both user i and user j select a service).
Preferably, the user characteristics of user i and user j can also be used to predict the probability of the user selecting a service for ij.
In step 410, a target user is selected to push traffic to the set based on the probability obtained in step 408.
For example, the probability of selecting a service may be ranked by user, and a plurality of top ranked user pairs may be selected to form the set of target user pairs.
As another example, a threshold may be set and if the probability of a user pair selecting a service is higher than the threshold, the user pair is determined to be the target user pair.
The push traffic may then be sent to the target user pair.
Optionally, the user's own user characteristics may also be used in the training model of step 404 and the prediction operation of step 408.
FIG. 5 is a process diagram for pushing traffic based on user pair relationships, according to aspects of the present disclosure.
At 501, characteristics of a first plurality of user pairs may be obtained.
The first plurality of user pairs may be formed from a first set of users. The first set of users may be a subset of a set of related users of the service (e.g., a set of potential users to purchase the service). For example, the first set of users may be a randomly selected subset of users, and data of the first set of users (e.g., user-to-relationship features, behavioral labels of the users) may be used to train the model. The users in the first set of users may be paired to form a user pair to form a first plurality of user pairs. Optionally, some user pairs with weaker relationships may be excluded from the first plurality of user pairs according to the strength of the relationships, thereby reducing the computational load of the training model.
The features of the first plurality of user pairs may include one or more relationship features for each user pair of the first plurality of user pairs. Optionally, the characteristics of the first plurality of user pairs may also include one or more user characteristics of each user of the first plurality of user pairs.
At 502, behavior tags for a first plurality of user pairs may be obtained.
For example, a service may be pushed to users in a first plurality of pairs of users in advance, and behavior tags for each user may be generated based on whether the user selects (clicks on or purchases) the service.
For example, if the user selects the service, the behavior tag of the user may be determined to be a first value; if the user does not select the service, the user's behavior tag may be determined to be a second value.
The model 504 may be trained using features of the first plurality of user pairs of 501 and behavior labels of the first plurality of user pairs of 502.
At 503, characteristics of a second plurality of user pairs may be obtained.
The second plurality of user pairs may be generated from a second set of users. The second set of users may be a set of related users of the service (e.g., a set of users who potentially purchase the service). The users in the second set of users may be paired to form a user pair to form a second plurality of user pairs. Optionally, some user pairs with weaker relationships may be eliminated from the second plurality of user pairs based on the strength of the relationship, thereby reducing the computational load of the prediction.
The features of the second plurality of user pairs may include one or more relationship features for each user pair of the second plurality of user pairs. Optionally, the characteristics of the second plurality of user pairs may also include one or more user characteristics of each user in the second plurality of user pairs.
The characteristics of the second plurality of user pairs may be input into the model 504 to predict behavioral data 505 for each user pair in the second plurality of user pairs, e.g., a probability of the user pair selecting (clicking on or purchasing) the service.
At 506, a target user may be determined from the behavior data 505.
For example, the behavioral data of the user pairs may be sorted, and the top ranked user pair may be selected as the target user pair.
Alternatively, the predicted behavior data of the user pair may be compared to a threshold, and if the predicted behavior data of the user pair is above the threshold, the user pair may be determined to be the target user pair.
At 507, traffic is pushed to the set of target user pairs.
Specifically, the service is pushed to each user in the target user pair set.
The method and the device use the relationship characteristics between the two users in the process of predicting the click rate/conversion rate of the service, and consider the relationship compactness of the two users, so that the pushing efficiency of the interactive service is effectively improved.
Preferably, in the process of selecting the training set of the training model and determining the target user pair by using the trained model, the user pair is screened by the relationship strength, so that the calculation amount can be reduced.
The illustrations set forth herein in connection with the figures describe example configurations and are not intended to represent all examples that may be implemented or fall within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration," and does not mean "preferred" or "advantageous over other examples. The detailed description includes specific details to provide an understanding of the described technology. However, the techniques may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form in order to avoid obscuring the concepts of the described examples.
In the drawings, similar components or features may have the same reference numerals. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
The various illustrative blocks and modules described in connection with the disclosure herein may be implemented or performed with a general purpose processor, a DSP, an ASIC, an FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).
The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope of the disclosure and the following claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hard-wired, or any combination thereof. Features that implement functions may also be physically located at various locations, including being distributed such that portions of functions are implemented at different physical locations. In addition, as used herein, including in the claims, "or" as used in a list of items (e.g., a list of items accompanied by a phrase such as "at least one of" or "one or more of") indicates an inclusive list, such that, for example, a list of at least one of A, B or C means a or B or C or AB or AC or BC or ABC (i.e., a and B and C). Also, as used herein, the phrase "based on" should not be read as referring to a closed condition set. For example, an exemplary step described as "based on condition a" may be based on both condition a and condition B without departing from the scope of the disclosure. In other words, the phrase "based on," as used herein, should be interpreted in the same manner as the phrase "based, at least in part, on.
Computer-readable media includes both non-transitory computer storage media and communication media, including any medium that facilitates transfer of a computer program from one place to another. Non-transitory storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, non-transitory computer-readable media can comprise RAM, ROM, electrically erasable programmable read-only memory (EEPROM), Compact Disk (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk (disk) and disc (disc), as used herein, includes CD, laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of computer-readable media.
The description herein is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.