CN111932349B

CN111932349B - Payment application recommendation method and device based on H5 payment

Info

Publication number: CN111932349B
Application number: CN202011040263.7A
Authority: CN
Inventors: 杨哲; 杨一鹏
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2020-09-28
Filing date: 2020-09-28
Publication date: 2021-01-26
Anticipated expiration: 2040-09-28
Also published as: CN111932349A

Abstract

The specification discloses a payment application recommendation method and device based on H5 payment. The method comprises the following steps: the payer processes an H5 payment request initiated by the user, acquires payment characteristics of the user after successful payment, and inputs the payment characteristics into the first recommendation submodel to obtain a payment recommendation result; the payer sends the payment recommendation result to the cooperative party; the service party receives the notification of successful payment sent by the payer, responds to the notification to acquire the service characteristics of the user, and inputs the service characteristics into the second recommendation submodel to obtain a service recommendation result; the business party sends the business recommendation result to the cooperative party; the cooperative party determines a comprehensive recommendation result according to the service recommendation result and the payment recommendation result and sends the comprehensive recommendation result to the payer; and the payer determines a target recommendation template according to the comprehensive recommendation result, and recommends the payment application to the user based on the target recommendation template.

Description

Payment application recommendation method and device based on H5 payment

Technical Field

The specification relates to the field of artificial intelligence, in particular to a payment application recommendation method and device based on H5 payment.

Background

With the development of technology, the application of H5 payment in human life is more and more extensive. "H5" refers generally to HTML5 and H5 payments are simply understood to be a payment scheme for making payments based on the payment page provided by the HTML5 standard. When the payment application developed by the payment service party is not installed on the terminal equipment of the user, the user can also realize payment through H5 payment.

However, H5 payment is often not convenient enough in actual use, for example, a user needs to input an account and a password on a payment page to log in, and may also input a short message verification code to perform identity verification, which results in poor user experience. How to recommend a payment application with better experience to a user becomes a key point of attention in the industry.

Disclosure of Invention

In view of the above, the present specification provides a payment application recommendation method and apparatus based on H5 payment.

Specifically, the description is realized by the following technical scheme:

a payment application recommendation method based on H5 payment realizes recommendation of a payment application based on a recommendation model obtained by joint training of a service party, a payment party and a cooperation party, wherein the payment party is deployed with a first recommendation submodel, and the service party is deployed with a second recommendation submodel, and comprises the following steps:

the payer processes an H5 payment request initiated by the user, acquires payment characteristics of the user after successful payment, and inputs the payment characteristics into the first recommendation submodel to obtain a payment recommendation result;

the payer sends the payment recommendation result to the cooperative party;

the service party receives the notification of successful payment sent by the payer, responds to the notification to acquire the service characteristics of the user, and inputs the service characteristics into the second recommendation submodel to obtain a service recommendation result;

the business party sends the business recommendation result to the cooperative party;

the cooperative party determines a comprehensive recommendation result according to the service recommendation result and the payment recommendation result and sends the comprehensive recommendation result to the payer;

and the payer determines a target recommendation template according to the comprehensive recommendation result, and recommends the payment application to the user based on the target recommendation template.

A payment application recommendation method based on H5 payment realizes recommendation of a payment application based on a recommendation model obtained by joint training of a service party, a payment party and a cooperation party, wherein the payment party is provided with a first recommendation submodel, the service party is provided with a second recommendation submodel, and the method is applied to the payment party and comprises the following steps:

processing an H5 payment request initiated by a user, acquiring payment characteristics of the user after payment is successful, and inputting the payment characteristics into the first recommendation submodel to obtain a payment recommendation result;

sending the payment recommendation result to a cooperative party;

receiving a comprehensive recommendation result determined by the cooperative party based on the payment recommendation result and the service recommendation result, wherein the comprehensive recommendation result is obtained by the service party responding to a payment success notification sent by the payer, acquiring the service characteristics of the user and inputting the service characteristics into the second recommendation submodel;

and determining a target recommendation template according to the received comprehensive recommendation result, and recommending the payment application to the user based on the target recommendation template.

A payment application recommendation device based on H5 payment realizes recommendation of a payment application based on a recommendation model obtained by joint training of a service party, a payment party and a cooperation party, wherein the payment party is provided with a first recommendation submodel, the service party is provided with a second recommendation submodel, and the device is applied to the payment party and comprises the following steps:

the processing unit is used for processing an H5 payment request initiated by a user, acquiring the payment characteristics of the user after the payment is successful, and inputting the payment characteristics into the first recommendation submodel to obtain a payment recommendation result;

the sending unit is used for sending the payment recommendation result to a cooperative party;

the receiving unit is used for receiving a comprehensive recommendation result determined by the cooperative party based on the payment recommendation result and the service recommendation result, wherein the comprehensive recommendation result is obtained by the service party responding to a payment success notification sent by the payer, acquiring the service characteristics of the user and inputting the service characteristics into the second recommendation submodel;

and the recommending unit is used for determining a target recommending template according to the comprehensive recommending result and recommending the payment application to the user based on the target recommending template.

a processor;

a memory for storing machine executable instructions;

wherein, by reading and executing machine executable instructions stored by the memory corresponding to H5 payment application recommendation logic, the processor is caused to:

sending the payment recommendation result to a cooperative party;

One embodiment of the specification realizes that a payer can process an H5 payment request initiated by a user, acquire payment characteristics of the user after payment is successful, input the payment characteristics into a first recommendation submodel, obtain a payment recommendation result and send the payment recommendation result to a cooperative party; the service party can receive the notification of successful payment sent by the payer, respond to the notification to acquire the service characteristics of the user, input the service characteristics into the second recommendation submodel, obtain the service recommendation result and send the service recommendation result to the cooperative party. The collaborator can determine a comprehensive recommendation result based on the payment recommendation result and the service recommendation result and return the comprehensive recommendation result to the payer. The payer may determine a target recommendation template based on the integrated recommendation result and recommend the payment application to the user using the target recommendation target.

By adopting the method, the recommendation model can be obtained through the data of the service party and the paying party and the joint training of the cooperation party, and after the H5 payment request initiated by the user is received, the target recommendation template which is more in line with the personalized preference of the user is determined based on the prediction result of the recommendation model, the feeling that the recommendation content is single and inapplicable is not caused to the user can not be caused, the user experience in the recommendation process is improved, and the recommendation success rate of the payment application can also be improved.

Drawings

FIG. 1 is a schematic diagram of a joint training method shown in an exemplary embodiment of the present description;

FIG. 2 is a schematic diagram of a payment application recommendation method based on H5 payment, shown in an exemplary embodiment of the present description;

FIG. 3 is a schematic diagram of another payment application recommendation method based on H5 payment as shown in an exemplary embodiment of the present description;

FIG. 4 is a schematic view of a page shown in an exemplary embodiment of the present description;

FIG. 5 is another schematic view of a page shown in an exemplary embodiment of the present description;

FIG. 6 is another schematic view of a page shown in an exemplary embodiment of the present description;

fig. 7 is a schematic structural diagram illustrating a payment application recommendation apparatus for H5-based payment according to an exemplary embodiment of the present specification;

fig. 8 is a block diagram illustrating an H5 payment based payment application recommendation apparatus according to an exemplary embodiment of the present specification.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of the present description.

The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

First, a business party and a payment party referred to in this specification will be described.

The business party may be a provider of the business service, and the business party may deploy a server or a server cluster as a server and develop client software, such as APP (Application), that may be loaded in the terminal device, and the user may use the business service on the APP and initiate a payment request. Wherein, the business service provided by the business party can be game service, shopping service, leasing service, ticket buying service, etc., and the payment request initiated by the user can be a recharging request, a payment request, etc.

The payer may be the provider of the payment service and similarly, the payer may also deploy a server or a cluster of servers, with the payment application being developed. After the user initiates the payment request at the service party, the payment party can process the payment request.

In one case, the user does not install the payment application on the terminal device, the user may obtain a payment page provided by the payer, and make a payment on the payment page (H5 payment). Due to the adoption of the mode, the payer does not know who initiates the current payment request, so that the user needs to manually input the account and the password on the payment page for logging in, and in order to ensure the safety of the account, the payer also needs to adopt a short message verification code and other modes for carrying out identity verification on the user, so that the H5 payment is not convenient and fast to operate in the implementation process, and the user experience is poor.

In another case, the user has installed the payment application on the terminal device, and then the user can pay directly through the payment application after initiating the payment request. And the payment application can acquire the logged-in user account information, the manual login process is generally not required to be executed by the user, and the payment operation is more convenient.

The specification provides a payment application recommendation method based on H5 payment, which can recommend payment applications to the user who adopts H5 payment, so that the user can directly use the payment applications for payment in subsequent payment after downloading and installing the payment applications, and the use experience of the user is improved.

However, in most cases, the users who initiate H5 payments are likely to be new users to the payer, or users who use the payment service less frequently, and the payer has little knowledge of the information of the users, and cannot make accurate and personalized recommendations based on the personal preferences of the users, and if the recommendations are not appropriate, the users will be disturbed.

The recommendation model can be obtained by joint training of user data of the service party and the payment party, the recommendation model is used for predicting the recommendation template, and more accurate personalized recommendation is realized based on the recommendation template. The recommendation template may generally include download controls for payment applications and various different types of recommendation documents.

The payer can set various recommendation templates, and different recommendation documents can be added into different recommendation templates, for example, the recommendation documents can be encouragement documents, reward documents, associated user documents, payment service documents and the like. Any one of the above documents may exist in each recommended template, or multiple documents may be combined in each recommended template, which is not limited in this embodiment.

The incentive scheme may include an incentive to encourage the user to download the payment application, such as "people are using the payment application, not expecting to try on" and "use the payment application, making the payment more convenient" and so on. The reward program may include the rights available to the user after downloading the payment application, such as a gift available after downloading, a member who has access to a platform after downloading, etc. The associated user copy may include associated user information for downloaded payment applications, such as a buddy list for downloading the payment applications, the buddy's rating of the payment applications, and so forth. The payment service copy may include several payment services provided by the payment application, such as water and electricity fee payment, traffic card recharge, face-swiping payment, credit payment, and the like. Of course, besides the above examples, the payer may also design other types of recommendation documents, and this embodiment is not particularly limited thereto.

In this embodiment, the recommendation model may be used to predict the recommendation template, multiple recommendation models may be used to predict the recommendation template, or only one recommendation model may be used to predict the recommendation template.

In one example, a recommendation template is predicted using a plurality of recommendation models, each for predicting a recommendation score for its corresponding recommendation template. For example, assuming that there are a recommendation model 1 corresponding to an incentive template (i.e., a template including the above-mentioned incentive document, the same applies below), a recommendation model 2 corresponding to an incentive template, and a recommendation model 3 corresponding to a payment service template, the service data of the user may be respectively input into the recommendation models 1 to 3 to obtain a recommendation score output by each recommendation model, and then a recommendation model corresponding to a highest recommendation score may be selected from the recommendation models to recommend a payment application to the user.

In another example, a recommendation model is used to predict the recommendation model. Corresponding recommendation score intervals can be set for the recommendation templates, after the recommendation models predict the probability (recommendation score) of success or failure of recommending payment applications to the user, the recommendation scores can be matched with the score intervals of the recommendation templates, and the payment applications are recommended to the user based on the matched recommendation templates.

In this embodiment, the payer and the service party may respectively select the payment sample characteristics and the service sample characteristics to train the recommendation model.

For the payer, for the case that there is one recommendation model or multiple recommendation models, the following methods may be respectively adopted to determine the payment sample user and the payment sample characteristics.

In one example, a plurality of recommendation models are used to predict a recommendation template. The payer may determine payment sample users and corresponding payment sample characteristics for each recommendation model, respectively. For example, for the recommendation model 1 corresponding to the incentive template, the payer may take the users who recommended the payment application in the form of the incentive document as sample users, and then obtain the payment sample characteristics of these sample users, such as: the recommendation frequency, the recommendation success rate, the latest recommendation time, and the like, the sample label may be that the recommendation success is 1, and the recommendation failure is 0. Similarly, for the recommendation model 2 corresponding to the reward template, the payer may use the user who recommended the payment application in the form of the reward program as a sample user, and then may also obtain the above payment sample characteristics and determine the sample label. The recommendation model corresponding to each recommendation template can adopt the method.

In another example, a recommendation model is used to predict recommendation templates. The payer may obtain, as a sample user, a user who has recommended the payment application once, and may, without limitation to the method of recommendation, recommend an incentive case, or recommend by another method. Payment sample characteristics of these users may also be obtained, such as: the recommendation frequency, the recommendation success rate, the latest recommendation time, and the like, the sample label may be that the recommendation success is 1, and the recommendation failure is 0.

Of course, in the above example, the payer may also obtain payment information of the user, such as payment amount, payment frequency, payment success rate, payment time, payment location, and basic information of the user, such as name, gender, age, address, etc., as the payment sample characteristics, which is not limited in this specification.

For the business party, for the case that there is one recommendation model or multiple recommendation models, the following method can be adopted to determine the business sample users and the corresponding business sample characteristics:

taking the business party as the shopping service provider as an example, the business sample user may be all users owned by the shopping service provider, or may be a part of users, for example, a user with a higher liveness, or a user who has been registered for a certain period of time. The service sample characteristics can be account information of the user, such as an account ID, an account level, activity of the account, an associated account of the account, and the like, and can also be behavior information of the user, such as browsing records, consumption records, recharging records, and the like of the user.

Since the business party does not have data related to recommending payment applications to the user, the business party does not have a sample tag.

The payer determines the payment sample characteristics and the sample labels, and after the business party determines the business sample characteristics, the payer and the business party can perform joint training by using the data to obtain a recommendation model. However, both the payer and the business may not want to reveal their data to each other as is during the co-training process. In this case, a collaborator may be added, and the collaborator may be considered as a third party where both the payer and the business party can be trusted. Therefore, the payer and the service party can send the encrypted data to the cooperation party, the cooperation party decrypts the encrypted data and sends the decrypted data needed by the two parties back to the cooperation party and the payment party, and the payment party and the cooperation party can jointly train to obtain the recommendation model under the condition that the original data of the payment party and the cooperation party are not exposed.

In this embodiment, since the user groups owned by the payer and the service party are likely to be different, there may be some users owned by both parties, or there may be some users not owned by the other party. For example, a user may have transacted business on a payment platform, with payment related business data. And the user does not purchase goods on a certain shopping platform, so that the user does not have shopping-related business data. In this case, the payer and the service may perform sample alignment before training the recommendation model, that is, may confirm the users shared by both parties without directly disclosing their respective original data, and may not expose mutually non-overlapping users, and subsequently train the model using the data of the shared users.

The method includes the steps that a service party and a payment party can conduct sample alignment, for example, the service party and the payment party can respectively utilize public keys of the service party and the payment sample to conduct encryption on service sample features and payment sample features, then encrypted data are sent to the service party, the service party and the payment party can decrypt the encrypted service sample and the encrypted payment sample by utilizing a private key after receiving the encrypted service sample and the encrypted payment sample, and then common users can be extracted according to identity information of the users. Of course, other sample alignment methods may be adopted, and refer to the related art specifically, which will not be described herein one by one.

After the samples are aligned, the recommended model can be trained by using the samples. The recommendation model in this embodiment may be a logistic regression model, or may be other models, which is not limited in this specification.

Referring to fig. 1, fig. 1 is a schematic diagram of a joint training method according to an exemplary embodiment of the present disclosure, and iterative training may be performed by using the method shown in fig. 1 until a training requirement is met.

It should be noted that in the embodiment shown in fig. 1, the service party and the payment party have performed sample alignment with each other, and then the service sample and the payment sample referred to in this embodiment are both samples corresponding to users owned by both parties, and these samples are all subjected to encryption processing.

The recommendation model can be trained by adopting an iterative training method, and in each iterative training, a business party and a payment party can respectively select a part of samples to train. For example, the business party and the payment party can select the business sample and the payment sample in the same time period in each iteration for training, so that the behavior of the user can be analyzed in the same time period, and the accuracy of model prediction is improved.

The following description will be given by taking an iterative training as an example.

The method of joint training may comprise the steps of:

and 102, training a second recommended sub-model by the service party based on the encrypted service sample.

And 104, the service party sends the encrypted prediction result to the payer.

The recommendation model in this embodiment is obtained by jointly training a payer, a cooperator, and a business party, where the payer may be trained with a first recommendation submodel, and the business party may be trained with a second recommendation submodel. The two sub-models can be understood as 'half-models' of the recommendation model and are respectively used for training to obtain a part of model parameters of the recommendation model, and the prediction function of the recommendation model can be realized based on the two sub-models.

In this embodiment, the service party may first train the second recommended sub-model using the own encrypted service sample to obtain an encrypted prediction result, and then send the encrypted prediction result to the payer.

And 106, training a first recommended sub-model by the payer based on the received encrypted prediction result and the own encrypted payment sample.

The payer may input the encrypted prediction result and the encrypted payment samples into a first recommended submodel to train the first recommended submodel.

In this step, the payer can also calculate an encryption loss value of the first recommended submodel in the iteration, then send the encryption loss value to the cooperator, and the cooperator can decrypt the encryption loss value and judge whether the decrypted loss value is smaller than a threshold value, if so, the recommendation model training is completed; if not, the recommendation model is not trained. And the cooperative party can also send a notice that the training is not completed to the paying party and the business party so as to inform the cooperative party and the paying party to continue to execute the next iteration.

In this embodiment, in the case that the training is not completed, the step 108 may be continuously executed.

And step 108, the payer calculates the encryption gradient of the first recommended submodel in the iteration.

In step 110, the payer sends the encrypted gradient of the first recommended submodel to the cooperator.

Step 112, the payer sends the gradient factor in the current iteration to the business party.

And step 114, the service party calculates the encryption gradient of the second recommended submodel in the iteration based on the gradient factor.

And step 116, the business party sends the encryption gradient of the second recommended submodel to the cooperative party.

In this embodiment, the payer may calculate the encryption gradient of the first recommended sub-model based on a gradient formula, and may send the gradient factor to the service party, so that the service party calculates the encryption gradient of the second recommended sub-model based on the gradient factor.

The above process is described below with a specific example:

assuming that the objective function of the recommendation model is the following formula (1):

wherein the content of the first and second substances,

model parameters for a second recommended submodel for the business party,

is the model parameters of the first recommended submodel for the payer,

to input a sample of the second recommended submodel,

for example, to enter a sample of the first recommended submodel, for a sample label,

in order to regularize the parameters of the process,

the value of (c) can be set manually.

The above-mentioned objective function is encrypted, and the encrypted objective function can be expressed as the following formula (2):

wherein the content of the first and second substances,

for the encrypted traffic sample of the traffic party,

a sample of the encrypted payment for the payer.

The gradient of the second recommended submodel and the gradient of the first recommended submodel are the following formula (3) and formula (4), respectively:

wherein the content of the first and second substances,

namely the factor of the gradient, is,

。

the payer may calculate the encryption gradient of the first recommended submodel in the iteration based on the formula (3), and then send the calculated value of the gradient factor to the service party. After receiving the gradient factor, the service party can calculate the encryption gradient of the first recommended sub-model by using the formula (4).

It should be noted that the objective function and the gradient factor of the above recommended model are only schematic illustrations, and other objective functions may be adopted in the present specification, which is not particularly limited.

And step 118, the cooperative party calculates the encryption total gradient of the recommendation model and decrypts the encryption total gradient based on the encryption gradient of the first recommendation submodel and the encryption gradient of the second recommendation submodel.

In this embodiment, after receiving the encryption gradient of the first recommended sub-model and the encryption gradient of the second recommended sub-model, the cooperator may calculate an encryption total gradient based on the two encryption gradients. The method for calculating the total encryption gradient is related to the type of the recommended model, for example, when the recommended model is a logistic regression model, the total encryption gradient can be calculated by a summation method. The cooperator may also decrypt the encrypted overall gradient, and the decryption method may correspond to the sample encryption method, such as RSA algorithm, which may be referred to in the related art.

The cooperator sends the decrypted total gradient to the payer, step 120.

In step 122, the payer updates the model parameters of the first recommended submodel based on the decrypted overall gradient.

Step 124, the collaborator sends the decrypted total gradient to the business party.

And step 126, the service party updates the model parameters of the second recommended sub-model based on the decrypted total gradient.

In this embodiment, after the cooperator calculates the decrypted total gradient, the cooperator may send the decrypted total gradient to the payer and the service provider, and then the payer and the service provider may update their respective model parameters based on the decrypted total gradient. The method for updating the model parameters refers to the related art, and is not described herein in detail.

Of course, in other examples, the collaborator may split the decrypted total gradient, for example, may split the total gradient in proportion to obtain a gradient corresponding to the first recommended sub-model and a gradient corresponding to the second recommended sub-model, and then directly send the split gradients to the payer and the service party, respectively, so that the payer and the service party may directly update their respective model parameters according to the received gradient corresponding to the payer and the service party.

And finishing the iterative training.

After the recommendation model is set forth in the joint training of the payer, the business party and the collaborator, the method for recommending payment application based on H5 payment provided in the present specification will be described below.

Referring to fig. 2, fig. 2 is a schematic diagram illustrating a payment application recommendation method based on H5 payment according to an exemplary embodiment of the present disclosure. The payment application recommendation method based on H5 payment can comprise the following steps:

step 202, a payer processes an H5 payment request initiated by a user, acquires payment characteristics of the user after successful payment, and inputs the payment characteristics into the first recommendation submodel to obtain a payment recommendation result;

step 204, the payer sends the payment recommendation result to the cooperative party;

step 206, the service party receives the notification of successful payment sent by the payer, responds to the notification to acquire the service characteristics of the user, and inputs the service characteristics into the second recommendation submodel to obtain a service recommendation result;

step 208, the business party sends the business recommendation result to the cooperative party;

step 210, the cooperative party determines a comprehensive recommendation result according to the service recommendation result and the payment recommendation result;

step 212, the cooperative party sends the comprehensive recommendation result to the paying party;

and 214, the payer determines a target recommendation template according to the comprehensive recommendation result, and recommends the payment application to the user based on the target recommendation template.

The above steps are explained in detail below.

In this embodiment, a user may initiate a payment request, where the payment request may have the following two situations: 1. calling a request initiated by an installed payment application on the terminal equipment; 2. a request initiated by a payment page (referred to herein as an H5 payment request) is invoked. The payer may determine whether the payment request is an H5 payment request through the interface information carried in the payment request, or may determine the payment request by other methods. The method described below in this specification is directed to an H5 payment request.

The payer can process an H5 payment request initiated by the user, acquire the payment characteristics of the user after successful payment, and input the payment characteristics into the first recommendation submodel to obtain a payment recommendation result.

The specific contents of the payment features can refer to the foregoing embodiments, and are not described herein again. It should be noted that, in this embodiment, the payment characteristics acquired by the payer are only used for being input into the first recommended sub-model deployed at the local side and are not leaked to the service party, so that the original payment characteristics may be directly input into the first recommended sub-model without encrypting the payment characteristics.

In this embodiment, after the payer succeeds in payment, the payer may also send a notification of successful payment to the service party. The notification may be sent before the payer obtains the payment feature or after the payer obtains the payment feature, which is not limited in this specification.

After receiving the notification of successful payment sent by the payer, the service party can respond to the notification to obtain the service characteristics of the user and input the service characteristics into the second recommendation submodel to obtain a service recommendation result.

The specific content of the service features may also refer to the foregoing embodiments, and the service features may also not be encrypted.

In this embodiment, the payment characteristics acquired by the payer and the service characteristics acquired by the service party may also belong to the same time period. For example, the payer may obtain the payment characteristics of the user in the last month, and the service party may obtain the service characteristics of the user in the last month. Therefore, the data of the user can be analyzed from the data in the same time period, and a prediction result closer to the personal habits and preferences of the user is obtained.

In this embodiment, the payer and the service party may send respective payment recommendation results and service recommendation results to the collaborating party, and the collaborating party may determine a comprehensive recommendation result based on the payment recommendation results and the service recommendation results.

For example, assuming that the recommendation model is a logistic regression model, the collaborator may sum the payment recommendation result and the service recommendation result, and determine a comprehensive recommendation result based on the sum result. The summation here may be direct summation, weighted summation, etc., and the summation method may be determined according to practical situations, which is not particularly limited in this specification.

In this embodiment, for the two recommendation models with different structures exemplified in the model training phase, the following two different comprehensive recommendation results can be obtained:

in one example, there are multiple recommendation models, one for each recommendation template. The integrated recommendation result may be a recommendation score output by each recommendation model, for example: the recommendation value of the incentive template corresponding to the recommendation model is 0.2, the recommendation value of the incentive template corresponding to the recommendation model is 0.7, and the recommendation value of the associated user template corresponding to the recommendation model is 0.1. The cooperative party can send the comprehensive recommendation result to the payer, and after receiving the comprehensive recommendation result, the payer can select a recommendation template with the highest recommendation score as a target recommendation template.

Of course, the collaborator may select the recommendation template with the highest recommendation score, and then return the identifier of the recommendation template to the payer, so that the payer may find the target recommendation template directly based on the identifier.

In another example, there is only one recommendation model, and the integrated recommendation result includes only one recommendation score, such as a probability of success of recommendation, e.g., 0.6 score, 0.3 score. The cooperative party can send the recommended value to the paying party, the paying party can have recommended value intervals corresponding to different recommended templates, and then the comprehensive recommended result is matched with each value interval to find out a matched target recommended template.

When the recommendation score intervals of the recommendation templates are set, the score intervals can be set according to the attraction degree of the recommendation templates to the user and the benefit degree of the user, for example, generally, the incentive templates only include an incentive scheme, the attraction degree to the user is low, and the score intervals can be set to be higher, such as 0.8-1.0; the payment service template may include some payment services provided by some payers, where the payment services may or may not include services interested by the user, and the attraction degree to the user is medium, and the score interval may be set to an intermediate state, such as 0.6-0.8; the reward template includes the rights to be rewarded to the user, such as a red envelope, a member, a coupon, etc., which may be more attractive to the user, and thus, the score interval thereof may be set to a lower state, such as 0.4 to 0.6. In this way, if the recommendation score of the user is predicted to be 0.9, and the recommendation success rate is high, the incentive template can be recommended to the user. If the recommendation score of the user is predicted to be 0.5, the recommendation success rate is low, and then the reward template with high attraction can be recommended to the user.

Of course, in the above example, similarly, the collaborator may also have score intervals corresponding to different recommendation templates, match the recommendation score with each score interval by the collaborator, and then return the identifier of the matched recommendation template to the payer, so that the payer may directly find the target recommendation template based on the identifier.

The specific content of the recommendation template refers to the foregoing embodiments, and is not described herein again.

In this embodiment, after the payer determines the target recommendation template, the payer may recommend the payment application to the user based on the target recommendation template. Such as the payer may present the target recommendation template on a payment results page paid at H5. The target recommendation template can be displayed at a preset position of the payment result page, and can also be displayed in a form of a suspension frame on the payment result page.

Of course, the target recommendation template may be presented in other manners, or may be presented on other pages, which is not limited in this specification.

It is worth mentioning that, although the above embodiments describe: the payer performs the steps of obtaining the payment characteristics, inputting the first recommended sub-model and the like after the payment is successful, but in practical cases, the payer may perform the steps of obtaining the payment characteristics, inputting the first recommended sub-model and the like before the payment is successful, for example, the payer may perform relevant steps after receiving an H5 payment request initiated by the user. In addition, the payer does not execute the relevant steps only when the payment is successful, and for the situations of payment failure, payment stagnation and the like, the payer can also execute the relevant steps and recommend the payment application to the user, and the specification does not specially limit the relevant steps.

As can be seen from the above description, in an embodiment of the present specification, a payer may process an H5 payment request initiated by a user, obtain payment characteristics of the user after successful payment, input the payment characteristics into a first recommendation sub-model, obtain a payment recommendation result, and send the payment recommendation result to a cooperator; the service party can receive the notification of successful payment sent by the payer, respond to the notification to acquire the service characteristics of the user, input the service characteristics into the second recommendation submodel, obtain the service recommendation result and send the service recommendation result to the cooperative party. The collaborator can determine a comprehensive recommendation result based on the payment recommendation result and the service recommendation result and return the comprehensive recommendation result to the payer. The payer may determine a target recommendation template based on the integrated recommendation result and recommend the payment application to the user using the target recommendation target.

Another payment application recommendation method based on H5 payment provided in this specification is described below. The method described in this embodiment is applied to a payer.

Referring to fig. 3, fig. 3 is a schematic diagram illustrating another payment application recommendation method based on H5 payment according to an exemplary embodiment of the present disclosure. The payment application recommendation method based on H5 payment can comprise the following steps:

step 302, process the user initiated H5 payment request.

Step 304, determine whether the payment was successful. If yes, go to step 306 and step 308.

Step 306, a notification of successful payment is sent to the business.

And 308, acquiring the payment characteristics of the user, and inputting the payment characteristics into the first recommendation submodel to obtain a payment recommendation result.

In this embodiment, after receiving an H5 payment request initiated by a user, a payer may process the H5 payment request and determine whether the payment is successful. If the payment is successful, on the one hand, a notification of successful payment can be sent to the service party; on the other hand, the payment characteristics of the user can be obtained, and the payment characteristics are input into the first recommendation submodel to obtain a payment recommendation result.

Step 306 may be executed before step 308, or may be executed after step 308, or both of the steps may also be executed in parallel, which is not limited in this embodiment.

And step 310, sending the payment recommendation result to the cooperative party.

And step 312, receiving the comprehensive recommendation result returned by the collaborator.

In this embodiment, the payer may send the recommendation to the collaborator. And after receiving the notification of successful payment sent by the payer in step 306, the service party may obtain the service characteristics of the user and input the second recommendation submodel to obtain the service recommendation result and send the service recommendation result to the collaborating party, so that the collaborating party obtains the comprehensive recommendation result based on the service recommendation result and the payment recommendation result. Reference may be made to the foregoing embodiments, and details are not repeated herein. The collaborator may return the integrated recommendation to the payer.

In this embodiment, it is assumed that there are 3 recommendation models respectively corresponding to the 3 recommendation templates, and the comprehensive recommendation result may be in the following form:

recommending a template 1, and recommending a score of 0.8;

recommending a template 2, and recommending a score of 0.2;

and recommending a template 3, and recommending a score of 0.4.

And step 314, determining a target recommendation template according to the comprehensive recommendation result.

In this embodiment, the recommendation template with the highest recommendation score may be determined as the target recommendation template. Still taking the above example as an example, the target recommendation template is recommendation template 1 with the highest recommendation score.

Step 316, determine whether the recommendation score of the target recommendation template is greater than a threshold. If so, go to step 318, otherwise, go to step 320.

Step 318, the target recommendation template is presented to the user.

At step 210, no payment application is recommended to the user.

In this embodiment, it may be determined whether the recommendation score of the target recommendation template is greater than a threshold, and if so, the target recommendation template is presented to the user, and if not, the target recommendation template is not presented to the user.

For example, the threshold may be 0.6, and then the recommendation score 0.8 of the target recommendation template (recommendation template 1) is greater than 0.6, so that the target recommendation template may be presented to the user.

By adopting the method, when the recommendation score of the target recommendation template is smaller than the threshold value, the user probably does not like the recommendation mode, and at the moment, if the payment application is recommended to the user possibly causes bad use experience, the payment application can not be recommended to the user, so that unnecessary disturbance to the user is avoided.

In this embodiment, the target recommendation template may be presented to the user in the following manner:

in one example, the target recommendation template may be presented in a payment results page.

For example, referring to fig. 4, a target recommendation template may be presented at a preset position of the payment result page shown in fig. 4, and the target recommendation template may include an incentive document: "Payment Using Payment application, Payment more convenient! "and download control" download immediately ".

For another example, referring to fig. 5, the target recommendation template may be presented in a form of a floating frame in the payment result page, for example, the target recommendation template may be in a red-pack shape, the target recommendation template may jump out automatically after jumping to the payment result page, and the target recommendation template may include a reward document: "download Payment application, pick up xx platform Red envelope" and download control "download immediately".

In another example, the target recommendation template may also be presented in a post-paid recommendation page, which may be page jumped based on payment results.

For example, referring to fig. 6, the user may click a "complete" button on the payment result page and then jump to the recommendation page. A target recommendation template may be presented in the recommendation page, which may include an encouragement note: "everyone uses the payment application, not just does not get up to the trial run", and may also show the associated user patterns, such as "friends Xiaoming", "friends Xiaojiang", "friends Xiaofang" in fig. 6 and the evaluation of the payment application by these friends. And the download control "download immediately" may be exposed as well.

Of course, in addition to the user clicking the "complete" button in the payment result page to jump to the recommended page, the user may also jump to the recommended page automatically after the display time of the payment result page to the user reaches the time threshold, or jump to the recommended page by other methods, which is not limited in this specification.

It should be noted that the content of the page schematic diagram and the target recommendation template of the client are schematic illustrations, and in an actual situation, the same page schematic diagram and the same target recommendation template as those in the above example are not necessarily adopted.

Step 322, receiving a downloading request initiated by the user based on the target recommendation template, and processing the downloading request.

In this embodiment, if the user wants to download the payment application, the user may click the download control in the target recommendation template to initiate a download request.

After receiving the download request, the payer may process the download request and perform operations related to downloading the payment application.

As can be seen from the above description, in an embodiment of the present specification, after a user initiates an H5 payment request and processes the payment request, payment characteristics of the user may be obtained, a comprehensive recommendation result may be obtained based on a recommendation model obtained by joint training of a payer, a service party, and a collaborator, a target recommendation template may be determined based on the comprehensive recommendation result, and it may also be determined whether a recommendation score of the target recommendation template is greater than a threshold value, if so, the recommendation template is displayed to the user, and if not, no payment application is recommended to the user.

Corresponding to the aforementioned embodiments of the payment application recommendation method based on H5 payment, the present specification also provides embodiments of a payment application recommendation device based on H5 payment.

The embodiment of the payment application recommendation device based on H5 payment in the specification can be applied to the server. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading corresponding computer program instructions in the nonvolatile memory into the memory for operation through the processor of the server where the device is located. From a hardware aspect, as shown in fig. 7, which is a schematic structural diagram of a payment application recommendation device based on H5 payment in this specification, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 7, a server where the device is located in the embodiment may also include other hardware according to an actual function of the server, which is not described again.

Referring to fig. 8, the payment application recommendation apparatus 800 based on H5 may be applied to the server shown in fig. 7, and includes a processing unit 810, a sending unit 820, a receiving unit 830, a recommendation unit 840, and a download processing unit 850.

The processing unit 810 processes an H5 payment request initiated by a user, acquires payment characteristics of the user after payment is successful, and inputs the payment characteristics into the first recommendation sub-model to obtain a payment recommendation result;

a sending unit 820, sending the payment recommendation result to the collaborator;

the receiving unit 830 is configured to receive a comprehensive recommendation result determined by the cooperative party based on the payment recommendation result and the service recommendation result, where the comprehensive recommendation result is obtained by the service party responding to a payment success notification sent by the payer, acquiring a service feature of a user, and inputting the service feature into the second recommendation sub-model;

and the recommending unit 840 determines a target recommending template according to the comprehensive recommending result and recommends the payment application to the user based on the target recommending template.

Optionally, the comprehensive recommendation result includes recommendation scores of a plurality of recommendation templates, and the recommending unit 840:

and determining the recommendation template with the highest recommendation score as the target recommendation template.

Optionally, the recommending unit 840:

judging whether the highest recommendation score is larger than a threshold value;

and if so, determining the recommendation template with the highest recommendation score as the target recommendation template.

Optionally, the recommending unit 840 further:

and if not, not recommending the payment application to the user.

Optionally, the recommending unit 840:

displaying the target recommendation template in a payment result page; or

And displaying the target recommendation template in a recommendation page, wherein the recommendation page is displayed after the payment result page skips.

Optionally, the payment feature and the service feature belong to the same time period.

Optionally, the recommendation template includes recommendation information, where the recommendation information includes one or more of the following:

an incentive document including an incentive phrase that encourages a user to download the payment application;

a reward document comprising an entitlement that a user may obtain after downloading the payment application;

an associated user copy, the associated user copy including associated user information that the payment application has been downloaded;

a payment service instrument comprising a number of payment services provided by the payment application.

Optionally, the recommendation template includes a download control of the payment application, and the apparatus further includes:

and a download processing unit 850 receiving a download request initiated by a user based on the download control, and processing the download request.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

Corresponding to the aforementioned embodiment of the payment application recommendation method based on H5 payment, the present specification further provides a payment application recommendation device based on H5 payment, which includes: a processor and a memory for storing machine executable instructions. Wherein the processor and the memory are typically interconnected by means of an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

In this embodiment, by reading and executing machine executable instructions stored by the memory corresponding to payment application recommendation logic for H5-based payments, the processor is caused to:

sending the payment recommendation result to a cooperative party;

Optionally, the integrated recommendation result includes recommendation scores of a plurality of recommendation templates, and when a target recommendation template is determined according to the integrated recommendation result, the processor is caused to:

Optionally, when the recommendation template with the highest recommendation score is determined to be the target recommendation template, the processor is caused to:

Optionally, the processor is further caused to:

and if not, not recommending the payment application to the user.

Optionally, when recommending the payment application to the user based on the target recommendation template, the processor is caused to:

displaying the target recommendation template in a payment result page; or

Optionally, the recommendation template includes a download control of the payment application, and the processor is further caused to:

and receiving a downloading request initiated by a user based on the downloading control, and processing the downloading request.

In correspondence with the aforementioned embodiments of the payment application recommendation method based on H5 payment, the present specification also provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps of:

sending the payment recommendation result to a cooperative party;

Optionally, the determining the target recommendation template according to the comprehensive recommendation result includes:

Optionally, the determining the recommendation template with the highest recommendation score as the target recommendation template includes:

Optionally, the method further includes:

and if not, not recommending the payment application to the user.

Optionally, the recommending the payment application to the user based on the target recommendation template includes:

displaying the target recommendation template in a payment result page; or

Optionally, the recommendation template includes a download control of the payment application, and the method further includes:

The foregoing description has been directed to specific embodiments of this disclosure. In some cases, the recited acts or steps may be performed in an order different than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.

Claims

1. A payment application recommendation method based on H5 payment realizes recommendation of a payment application based on a recommendation model obtained by joint training of a service party, a payment party and a cooperation party, wherein the payment party is provided with a first recommendation submodel, the service party is provided with a second recommendation submodel, and the method is applied to the payment party and comprises the following steps:

processing an H5 payment request initiated by a user, acquiring payment characteristics of the user after payment is successful, and inputting the payment characteristics into the first recommendation submodel to obtain a payment recommendation result, wherein the payment characteristics comprise recommendation information of a payment application;

sending the payment recommendation result to a cooperative party;

receiving a comprehensive recommendation result determined by a cooperative party based on the payment recommendation result and a service recommendation result, wherein the service recommendation result is obtained by a service party responding to a payment success notice sent by a payer, acquiring service characteristics of a user and inputting the service characteristics into the second recommendation submodel, and the service characteristics comprise behavior information of the user on the service party;

and determining a target recommendation template according to the comprehensive recommendation result, and recommending the payment application to a user based on the target recommendation template.

2. The method of claim 1, wherein the integrated recommendation comprises recommendation scores for a plurality of recommendation templates, and wherein determining a target recommendation template based on the integrated recommendation comprises:

3. The method of claim 2, wherein determining the recommendation template with the highest recommendation score as the target recommendation template comprises:

4. The method of claim 3, further comprising:

and if not, not recommending the payment application to the user.

5. The method of claim 1, the recommending the payment application to the user based on the target recommendation template, comprising:

displaying the target recommendation template in a payment result page; or

6. The method of claim 1, wherein the payment characteristic and the business characteristic belong to the same time period.

7. The method of claim 2, wherein the recommendation template comprises recommendation information, the recommendation information comprising one or more of:

8. The method of claim 2, the recommendation template including a download control for the payment application therein, the method further comprising:

9. The method according to any one of claims 1 to 8,

the payment features include: payment amount, payment frequency, payment success rate, payment application recommendation times, payment application recommendation method and payment application recommendation success rate;

the service features include: account level, account liveness, recharge records, consumption records, and browsing records.

10. A payment application recommendation device based on H5 payment realizes recommendation of a payment application based on a recommendation model obtained by joint training of a service party, a payment party and a cooperation party, wherein the payment party is provided with a first recommendation submodel, the service party is provided with a second recommendation submodel, and the device is applied to the payment party and comprises the following steps:

the processing unit is used for processing an H5 payment request initiated by a user, acquiring payment characteristics of the user after payment is successful, and inputting the payment characteristics into the first recommendation submodel to obtain a payment recommendation result, wherein the payment characteristics comprise recommendation information of payment application;

the receiving unit is used for receiving a comprehensive recommendation result determined by the cooperative party based on the payment recommendation result and the service recommendation result, wherein the service recommendation result is obtained by the service party responding to a payment success notice sent by the payer, acquiring the service characteristics of the user and inputting the service characteristics into the second recommendation submodel, and the service characteristics comprise behavior information of the user on the service party;

11. The apparatus of claim 10, wherein the integrated recommendation includes recommendation scores for a number of recommendation templates, and wherein the recommending unit:

12. The apparatus of claim 11, the recommendation unit to:

13. The apparatus of claim 12, the recommendation unit further to:

and if not, not recommending the payment application to the user.

14. The apparatus of claim 10, the recommendation unit to:

displaying the target recommendation template in a payment result page; or

15. The apparatus of claim 10, wherein the payment characteristic and the service characteristic belong to the same time period.

16. The apparatus of claim 11, the recommendation template comprises recommendation information, the recommendation information comprising one or more of:

17. The apparatus of claim 11, the recommendation template including a download control for the payment application therein, the apparatus further comprising:

and the download processing unit is used for receiving a download request initiated by a user based on the download control and processing the download request.

18. The apparatus according to any one of claims 10 to 17,

19. A payment application recommendation device based on H5 payment realizes recommendation of a payment application based on a recommendation model obtained by joint training of a service party, a payment party and a cooperation party, wherein the payment party is provided with a first recommendation submodel, the service party is provided with a second recommendation submodel, and the device is applied to the payment party and comprises the following steps:

a processor;

a memory for storing machine executable instructions;

sending the payment recommendation result to a cooperative party;