CN106453593A - 一种消息推送方法及装置 - Google Patents

一种消息推送方法及装置 Download PDF

Info

Publication number
CN106453593A
CN106453593A CN201610945481.2A CN201610945481A CN106453593A CN 106453593 A CN106453593 A CN 106453593A CN 201610945481 A CN201610945481 A CN 201610945481A CN 106453593 A CN106453593 A CN 106453593A
Authority
CN
China
Prior art keywords
server end
interaction server
social
social interaction
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201610945481.2A
Other languages
English (en)
Other versions
CN106453593B (zh
Inventor
孙子荀
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology Shenzhen Co Ltd
Original Assignee
Tencent Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology Shenzhen Co Ltd filed Critical Tencent Technology Shenzhen Co Ltd
Priority to CN201610945481.2A priority Critical patent/CN106453593B/zh
Publication of CN106453593A publication Critical patent/CN106453593A/zh
Application granted granted Critical
Publication of CN106453593B publication Critical patent/CN106453593B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/55Push-based network services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明实施例公开了一种消息推送方法及装置,其中,消息推送方法包括:接收各个社交服务端发送的针对同一社交客户端的消息推送请求;根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级;根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端;将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。本发明实施例能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了社交服务端与社交客户端的相对融合与平衡。

Description

一种消息推送方法及装置
技术领域
本发明实施例涉及通信技术领域,具体涉及一种消息推送方法及装置。
背景技术
随着通信技术的发展,利用社交平台进行消息推送已成为企业或商家发布消息、用户获取消息的主要渠道之一。用户可以关注或添加多个社交公众号,每个社交公众号对应的社交服务端都可以给用户推送消息,希望更多的用户能使用其服务,随着社交公众号业务的不断增多,推送消息的数量也会大大增加,导致消息推送过渡,给用户造成了极大的骚扰。
发明内容
有鉴于此,本发明实施例提供了一种消息推送方法及装置,能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了服务端与客户端的相对融合与平衡。
本发明实施例提供的消息推送方法,包括:
接收各个社交服务端发送的针对同一社交客户端的消息推送请求;
根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级;
根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端;
将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。
本发明实施例提供的消息推送装置,包括:
接收单元,用于接收各个社交服务端发送的针对同一社交客户端的消息推送请求;
第一确定单元,用于根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级;
第二确定单元,用于根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端;
发送单元,用于将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。
本发明实施例中,在接收到各个社交服务端发送的针对同一社交客户端的消息推送请求之后,会根据各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级,根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端,将具有消息推送权的社交服务端的推送消息发送给所述社交客户端,由于在消息推送的过程中,同时考量了社交服务端的得分情况及社交客户端的接收情况,因而能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了社交服务端与社交客户端的相对融合与平衡。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例所提供的消息推送方法的一个场景示意图;
图2是本发明实施例所提供的消息推送方法的一个流程示意图;
图3是本发明实施例所提供的消息推送方法的另一流程示意图;
图4是本发明实施例所提供的消息推送装置的一个结构示意图;
图5是本发明实施例所提供的消息推送装置的另一结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
现有的消息推送方法,没有有效、合理的控制机制,导致消息推送过渡,给用户造成了极大的骚扰,因而,本发明实施例提供了一种消息推送方法及装置,能够避免消息推送过渡给用户造成的骚扰,本发明实施例提供的消息推送方法可实现在消息推送装置中,消息推送装置可以是社交公众平台的服务器。本发明实施例消息推送方法一个具体实施场景可如图1所示,包括若干社交服务端、控制端及社交客户端,社交服务端可以指社交公众号(例如微信公众号、QQ公众号)对应的后台终端(例如企业或商家的,用于通过社交公众号给用户推送消息的手机、平板电脑等终端设备),一个社交公众号可以对应一个社交服务端;控制端可以是社交公众平台的服务器;社交客户端可以是社交账号(例如微信号、QQ号)对应的用户侧的终端设备(例如用户的手机、平板电脑等终端设备,用户侧通过在终端设备上登陆社交账号接收社交公众号推送的消息)。通常来说,每个社交公众号(即社交服务端)会将推送任务发送至社交公众平台(即控制端),社交公众平台将各个推送任务放入发送队列,当有推送任务到达对应社交公众号设置的发送时间时,社交公众平台就将该推送任务发送给对应的社交账号(即社交客户端)。
本发明实施例提供的方法可用于控制端,当各个社交服务端要向同一社交客户端推送消息时,各个社交服务端可以向控制端发送消息推送请求,控制端接收各个社交服务端发送的消息推送请求,然后根据各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定各个社交服务端的推送优先级,根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端,将具有消息推送权的社交服务端的推送消息发送给所述社交客户端,将没有消息推送权的社交服务端的推送消息丢弃,由于同时考量了社交服务端的得分情况及社交客户端的接收情况,因而能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了社交服务端与社交客户端的相对融合与平衡。
以下分别进行详细说明,需说明的是,以下实施例的序号不作为对实施例优选顺序的限定。
实施例一
如图2所示,本实施例的方法包括以下步骤:
步骤201、接收各个社交服务端发送的针对同一社交客户端的消息推送请求;
具体实现中,社交服务端可以指社交公众号(例如微信公众号、QQ公众号)对应的后台终端,例如企业或商家的,用于通过社交公众号给社交客户端推送消息的手机、平板电脑等终端设备。社交客户端可以指用户侧的终端设备,例如用户侧的用于通过社交账号(例如微信号、QQ号)接收企业或商家推送消息的手机、平板电脑等终端设备。
用户可以在社交客户端上登陆对应的社交账号,通过对应的社交账号关注或添加企业、商家的社交公众号,当企业、商家有消息要推送给用户时,通过对应社交服务端上登陆的社交公众号向控制端发送消息推送请求,控制端接收各个社交服务端发送的消息推送请求。
消息推送请求中可以包括社交服务端的标识信息(例如企业或商家的社交公众号)、消息内容、以及社交客户端的标识信息(例如用户的社交账号)。如果多个社交服务端要向同一社交客户端推送消息,则多个社交服务端发送的消息推送请求中将包含同一社交客户端的标识信息。
步骤202、根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级;
具体地,每个社交服务端的多维度特征信息包括下述至少一项:该社交服务端与所述社交客户端之间的互动信息,该社交服务端推送消息的新鲜度,针对该社交服务端设置的运营策略,该社交服务端推送消息的预估点击率,和所述社交客户端对该社交服务端推送消息所涉及的产品的出价。
在一个具体的实施例中,每个社交服务端的推送优先级可以通过计算对应社交服务端的调度分得到,每个社交服务端的调度分等于,该社交服务端的各维度特征信息得分与对应维度权重的乘积之和。下面分别解释各维度特征信息得分的衡量方法:
(1)互动性得分;
即该社交服务端与所述社交客户端之间的互动性得分,一种简单可行的打分方式是:统计在过去预设时间段内(例如一个周、一个月等),社交客户端对各个社交服务端推送的消息的反馈情况,根据社交客户端的反馈情况确定对应社交服务端的互动性得分。
例如,在过去一周,对于某个社交服务端推送的消息,社交客户端如果有用户阅读行为则该社交服务端得到1分的互动性得分,有点击行为则该社交服务端得到3分,有转发行为则该社交服务端得到5分,有删除行为则扣除该社交服务端的互动性得分3分。
(2)新鲜度得分;
即该社交服务端推送消息的新鲜度得分,新鲜度得分可以通过社交服务端对社交客户端的曝光程度来考量,如果一个社交服务端一连几天都给社交客户端推送了消息,则曝光过度,那么可能会导致这个社交客户端不能从该社交服务端获得更新鲜的数据,该社交服务端的新鲜度得分就要做相应的扣减,反之,如果一个社交服务端一连几天都未对社交客户端推送消息,曝光过少,则可以给该社交服务端的新鲜度得分增加几分。
例如统计时间为1周,如果某个社交服务端连续7天都给社交客户端推送了信息,则每天扣一分,将该社交服务端的新鲜度得分扣掉7分;反之,如果某个社交服务端连续7天都未给社交客户端推送信息,则每天加1分,将该社交服务端的新鲜度得分增加7分。
(3)运营策略得分;
即针对该社交服务端设置的运营策略得分,运营策略得分可通过人工干预来实现,当需要推广某个社交服务端提供的服务时,可以给该社交服务端较高的运营策略得分,当需要弱化某个社交服务端提供的服务时,可以给该社交服务端较低的运营策略得分。
例如,在“双11”的时候,我们需要给购物类的社交服务端较高赢得用户的概率,则可以给该社交服务端100分的运营策略得分,而对于其他的社交服务端(例如新闻、游戏类的社交服务端),则给50分或0分的运营策略得分。
(4)预估点击率得分;
即该社交服务端推送消息的预估点击率得分,预估点击率得分可以基于点击率训练模型来计算,具体地,可以采用通用的迭代决策树(Gradient Boosting Decision Tree,GBRT)做特征组合,逻辑回归(Logistic Regression,LR)做点击率模型训练,训练结果用于线上实时计算社交服务端推送消息的点击率,具体的计算过程可参阅现有技术,此处不再赘述。
(5)出价得分;
即所述社交客户端对该社交服务端推送消息所涉及的产品的出价得分,出价得分可以通过社交客户端对社交服务端推送消息所涉及的产品购买意向来确定。如果社交客户端愿意出价购买社交服务端推送消息所涉及的产品,那么我们可以给该社交服务端较高的出价得分,反之,可以给该社交服务端较低的出价得分。
具体地,针对以上五个维度特征信息得分,可以得出如下公式计算每个社交服务端的调度分:
调度分=w1*互动性得分+w2*新鲜度得分+w3*运营策略得分+w4*预估点击率得分+w5*出价得分。
其中,w1、w2、w3、w4、w5对应为各个维度的权重,每个维度对应的权重的取值可视实际需求自定义。
从上面的描述可以看出,调度分的打分机制融合了控制端的考虑(运营策略得分),客户端的考虑(互动性得分),服务端的考虑(新鲜度得分),平台生态的考虑(价格得分,预估点击率得分),调度分越高的社交服务端,将具有越高的推送优先级,以此来控制消息的推送,可以使消息的推送更精准,更具针对性。
步骤203、根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端;
为避免推送消息过多给用户造成骚扰,可以为社交客户端设置接收频次上限,即设置社交客户端在预设时间长度内可接收推送消息的数量上限,例如可以设置一个社交客户端每天最多可以接收6条或8条推送消息等,控制端加以控制,如果各个社交服务端推送的消息累积起来超过了6条或8条,则将后续推送的消息丢弃掉,即先到先得的控制机制。这样一来,如果在未来某个时间段内,各个社交服务端将要推送给某个社交客户端的消息的数量之和,大于该社交客户端在该时间段内可接收消息的数量上限时,各个社交服务端之间就需要竞争消息推送权。
具体在本实施例中,可以将先到先得的控制机制与推送优先级结合起来,用于确定具有消息推送权的社交服务端,以避免各个社交服务端之间的不良竞争,即在某个时间段内,已发送消息推送请求,且推送优先级较高的社交服务端,才具有较高赢得消息推送权的概率。
另外,为了兼顾突发性的推送任务,保证推送消息的实时性,可以将社交客户端在某个时间段内的可接收频次均匀随机释放。例如,社交客户端在接下来的一天内有6个可接收频次(即可以接收6条推送消息),那么可以从0点开始,每隔4小时(这个间隔称之为竞争时间区间)随机释放一个可接收频次(即每个竞争时间区间内的可接收消息数量为1),24小时内将释放6个可接收频次,这样各个社交服务端在对应竞争时间区间内只能竞争该竞争时间区间之内的推送频次,而当前竞争时间区间没有被消耗的频次将自动保存到下一竞争时间区间。
具体可按照如下方式确定具有消息推送权的社交服务端:
首先按照推送优先级从高到低的顺序依次选取预设数量的社交服务端,所述预设数量的取值与所述社交客户端在预设竞争时间区内的可接收消息数量的取值相同;本实施例中,可以认为社交服务端每发送一次消息推送请求,就有一条消息要推送给社交客户端,所选取的社交服务端的数量与要推送消息的数量相同;
然后确定所选取的预设数量的社交服务端为具有消息推送权的社交服务端。
步骤204、将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。
另外,可以将没有消息推送权的社交服务端的推送消息丢弃掉。
本实施例中,在接收到各个社交服务端发送的针对同一社交客户端的消息推送请求之后,会根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级,根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端,将具有消息推送权的社交服务端的推送消息发送给所述社交客户端,由于在消息推送的过程中,同时考量了社交服务端的得分情况及社交客户端的接收情况,因而能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了社交服务端与社交客户端的相对融合与平衡。
实施例二
实施例一所描述的方法,本实施例将举例作进一步详细说明,如图3所示,本实施例的方法包括:
步骤301、接收各个社交服务端发送的针对同一社交客户端的消息推送请求;
具体实现中,社交服务端可以指社交公众号(例如微信公众号、QQ公众号)对应的后台终端,例如企业或商家的,用于通过社交公众号给社交客户端推送消息的手机、平板电脑等终端设备。社交客户端可以指用户侧的终端设备,例如用户侧的用于通过社交账号(例如微信号、QQ号)接收企业或商家推送消息的手机、平板电脑等终端设备。
用户可以在社交客户端上登陆对应的社交账号,通过对应的社交账号关注或添加企业、商家的社交公众号,当企业、商家有消息要推送给用户时,通过对应社交服务端上登陆的社交公众号向控制端发送消息推送请求,控制端接收各个社交服务端发送的消息推送请求。
消息推送请求中可以包括社交服务端的标识信息(例如企业或商家的社交公众号)、消息内容、以及社交客户端的标识信息(例如用户的社交账号)。如果多个社交服务端要向同一社交客户端推送消息,则多个社交服务端发送的消息推送请求中将包含同一社交客户端的标识信息。
步骤302、根据所述社交客户端与所述各个社交服务端之间的活跃度及预设对应关系,获取所述各个社交服务端的消息推送上限;
活跃度可以采用打分机制衡量,可以统计在过去预设时间段内(例如一个周、一个月等),社交客户端对各个社交服务端推送的消息的反馈情况,根据社交客户端的反馈情况确定所述社交客户端与对应社交服务端之间的活跃度。
例如,在过去一周,对于某个社交服务端推送的消息,社交客户端如果有用户阅读行为则该社交服务端得到1分的活跃度得分,有点击行为则该社交服务端得到3分,有转发行为则该社交服务端得到5分,有删除行为则扣除该社交服务端的活跃度得分3分。活跃度得分越高,说明社交客户端对对应社交服务端推送的消息越感兴趣,可以认为社交客户端越愿意接收该社交服务端推送的消息。
预设对应关系即预先设置的活跃度与消息推送上限的对应关系,不同活跃度可以对应不同的消息推送上限,活跃度越高,可以为对应社交服务端设置越高的消息推送上限。例如社交客户端与社交服务端B1之间的活跃度为10,与社交服务端B2之间的活跃度为2,则可以设置B1的消息推送上限为3(即B1在预设时间段内最多可以推送3条消息给社交客户端),B2的消息推送上限为1(即B2在预设时间段内最多可以推送1条消息给社交客户端)。根据预设对应关系及社交客户端与各个社交服务端之间的活跃度,即可得到各个社交服务端的消息推送上限。
步骤303、从所述各个社交服务端中,去除消息推送数量已达对应消息推送上限的社交服务端;
如果在预设时间段内,一个社交服务端累积推送消息的数量已达其消息推送上限,则去除该社交服务端,在该预设时间段内,将不再将该社交服务端的推送消息发送给社交客户端。
步骤304、判断剩余社交服务端推送消息的数量之和是否大于所述社交客户端在预设时间区间内的可接收消息数量,若大于,则执行步骤305,否则,执行步骤309;
剩余社交服务端,即从上述各个社交服务端中,去除消息推送数量已达对应消息推送上限的社交服务端之后剩余的社交服务端。
为避免推送消息过多给用户造成骚扰,可以为社交客户端设置接收频次上限,即设置社交客户端在预设时间长度内可接收推送消息的数量上限,例如可以设置一个社交客户端每天最多可以接收6条或8条推送消息等,控制端加以控制,如果各个社交服务端推送的消息累积起来超过了6条或8条,则将后续推送的消息丢弃掉,即先到先得的控制机制。
这样一来,如果在未来某个时间段内,各个剩余社交服务端将要推送给某个社交客户端的消息的数量之和,大于该社交客户端在该时间段内可接收消息的数量上限时,则各个剩余社交服务端之间就需要竞争消息推送权;反之,如果各个剩余社交服务端将要给该社交客户端的消息的数量之和,不大于该社交客户端在该时间段内可接收消息的数量上限,则不需要竞争,所有剩余社交服务端的推送消息都可以直接发送给社交客户端。
步骤305、确定所述剩余社交服务端的推送优先级;
具体地,可以根据每个剩余社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定每个剩余社交服务端的推送优先级。每个社交服务端的多维度特征信息包括下述至少一项:该剩余社交服务端与所述社交客户端之间的互动信息,该剩余社交服务端推送消息的新鲜度,针对该剩余社交服务端设置的运营策略,该剩余社交服务端推送消息的预估点击率,和所述社交客户端对该剩余社交服务端推送消息所涉及的产品的出价。
在一个具体的实施例中,每个剩余社交服务端的推送优先级可以通过计算对应剩余社交服务端的调度分得到,每个剩余社交服务端的调度分等于,该剩余社交服务端的各维度特征信息得分与对应维度权重的乘积之和。以上五个维度特征信息得分的具体衡量方法可参阅实施例一的描述,此处不再赘述。
具体针对以上五个维度特征信息得分,可以得出如下公式计算每个剩余社交服务端的调度分:
调度分=w1*互动性得分+w2*新鲜度得分+w3*运营策略得分+w4*预估点击率得分+w5*出价得分。
其中,w1、w2、w3、w4、w5对应为各个维度的权重,每个维度对应的权重的取值可视实际需求自定义。
从上面的描述可以看出,调度分的打分机制融合了控制端的考虑(运营策略得分),客户端的考虑(互动性得分),服务端的考虑(新鲜度得分),平台生态的考虑(价格得分,预估点击率得分),调度分越高的社交服务端,将具有越高的推送优先级,以此来控制消息的推送,可以使消息的推送更精准,更具针对性。
步骤306、从所述剩余社交服务端中,按照推送优先级从高到低的顺序依次选取预设数量的社交服务端,所述预设数量的取值与所述可接收消息数量的取值相同;
本实施例中,可以认为社交服务端每发送一次消息推送请求就有一条消息要推送,所选取的剩余社交服务端的数量与要推送消息的数量相同。
步骤307、确定所选的预设数量的社交服务端为具有消息推送权的社交服务端;
步骤308、将具有消息推送权的社交服务端的推送消息发送给所述社交客户端;
具体在本实施例中,可以将先到先得的控制机制与推送优先级结合起来,用于确定具有消息推送权的社交服务端,以避免各个社交服务端之间的不良竞争,即在某个时间段内,已发送消息推送请求,消息推送数量未达对应消息推送上限,且推送优先级较高的社交服务端,才具有较高赢得消息推送权的概率。
另外,为了兼顾突发性的推送任务,保证推送消息的实时性,可以将社交客户端在某个时间段内的可接收频次均匀随机释放。例如,社交客户端在接下来的一天内有6个可接收频次(即可以接收6条推送消息),那么可以从0点开始,每隔4小时(这个间隔称之为竞争时间区间)随机释放一个可接收频次(即每个竞争时间区间内的可接收消息数量为1),24小时内将释放6个可接收频次,这样各个剩余社交服务端在对应竞争时间区间内只能竞争该竞争时间区间之内的推送频次,而当前竞争时间区间没有被消耗的频次将自动保存到下一竞争时间区间。
步骤309、将所述剩余社交服务端的推送消息发送给所述社交客户端。
下面举例说明本发明实施例提供的消息推送方法,例如社交服务端B1、B2、B3的消息推送数量均未达到对应的消息推送上限,在竞争时间区间8:00-12:00内,社交服务端B1、B2、B3各有一条消息要推送给客户端C,而在该竞争时间区内,客户端C只有两个可接收频次,计算得到的B1的调度分为3.7,B2的调度分为2.2,B3的调度分为0.4,推送优先级从高到低依次为B1>B2>B3,则B1、B2将竞争得到在该时间区内的消息推送权。在该时间区间内的可接收频次释放之后,控制端可以将B1、B2的推送消息发送给客户端C,将B3的推送消息丢弃。
本实施例中,在接收到各个社交服务端发送的针对同一社交客户端的消息推送请求之后,会根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级,根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端,将具有消息推送权的社交服务端的推送消息发送给所述社交客户端,由于在消息推送的过程中,同时考量了社交服务端的得分情况及社交客户端的接收情况,因而能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了社交服务端与社交客户端的相对融合与平衡。
实施例三
为了更好地实施以上方法,本发明实施例还提供一种消息推送装置,如图4所示,本实施例的消息推送装置包括:接收单元401、第一确定单元402、第二确定单元403及发送单元404,如下:
(1)接收单元401;
接收单元401,用于接收各个社交服务端发送的针对同一社交客户端的消息推送请求。
具体地,消息推送请求中可以包括社交服务端的标识信息(例如企业或商家的社交公众号)、消息内容、以及社交客户端的标识信息(例如用户的社交账号)。如果多个社交服务端要向同一社交客户端推送消息,则多个社交服务端发送的消息推送请求中将包含同一社交客户端的标识信息。
(2)第一确定单元402;
第一确定单元402,用于根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级。
具体地,每个社交服务端的多维度特征信息包括下述至少一项:该社交服务端与所述社交客户端之间的互动信息,该社交服务端推送消息的新鲜度,针对该社交服务端设置的运营策略,该社交服务端推送消息的预估点击率,和所述社交客户端对该社交服务端推送消息所涉及的产品的出价。
在一个具体的实施例中,第一确定单元402可以通过计算各个社交服务端的调度分确定各个社交服务端的推送优先级,所计算的每个社交服务端的调度分等于,该社交服务端的各维度特征信息得分(即互动性得分、新鲜度得分、运营策略得分、预估点击率得分、出价得分)与对应维度权重的乘积之和。
其中,互动性得分的衡量方法可如下:
统计在过去预设时间段内(例如一个周、一个月等),社交客户端对各个社交服务端推送的消息的反馈情况,根据社交客户端的反馈情况确定对应社交服务端的互动性得分。例如,在过去一周,对于某个社交服务端推送的消息,社交客户端如果有用户阅读行为则该社交服务端得到1分的互动性得分,有点击行为则该社交服务端得到3分,有转发行为则该社交服务端得到5分,有删除行为则扣除该社交服务端的互动性得分3分。
新鲜度得分的衡量方法可如下:
新鲜度得分可以通过社交服务端对社交客户端的曝光程度来考量,如果一个社交服务端一连几天都给社交客户端推送了消息,则曝光过度,那么可能会导致这个社交客户端不能从该社交服务端获得更新鲜的数据,该社交服务端的新鲜度得分就要做相应的扣减,反之,如果一个社交服务端一连几天都未对社交客户端推送消息,曝光过少,则可以给该社交服务端的新鲜度得分增加几分。例如统计时间为1周,如果某个社交服务端连续7天都给社交客户端推送了信息,则每天扣一分,将该社交服务端的新鲜度得分扣掉7分;反之,如果某个社交服务端连续7天都未给社交客户端推送信息,则每天加1分,将该社交服务端的新鲜度得分增加7分。
运营策略得分的衡量方法可如下:
运营策略得分可通过人工干预来实现,当需要推广某个社交服务端提供的服务时,可以给该社交服务端较高的运营策略得分,当需要弱化某个社交服务端提供的服务时,可以给该社交服务端较低的运营策略得分。例如,在“双11”的时候,我们需要给购物类的社交服务端较高赢得用户的概率,则可以给该社交服务端100分的运营策略得分,而对于其他的社交服务端(例如新闻、游戏类的社交服务端),则给50分或0分的运营策略得分。
预估点击率得分的衡量方法可如下:
预估点击率得分可以基于点击率训练模型来计算,具体地,可以采用通用的迭代决策树(Gradient Boosting Decision Tree,GBRT)做特征组合,逻辑回归(LogisticRegression,LR)做点击率模型训练,训练结果用于线上实时计算社交服务端推送消息的点击率,具体的计算过程可参阅现有技术,此处不再赘述。
出价得分的衡量方法可如下:
出价得分可以通过社交客户端对社交服务端推送消息所涉及的产品购买意向来确定。如果社交客户端愿意出价购买社交服务端推送消息所涉及的产品,那么我们可以给该社交服务端较高的出价得分,反之,可以给该社交服务端较低的出价得分。
针对以上五个维度特征信息得分,可以得出如下公式计算每个社交服务端的调度分:
调度分=w1*互动性得分+w2*新鲜度得分+w3*运营策略得分+w4*预估点击率得分+w5*出价得分。
其中,w1、w2、w3、w4、w5对应为各个维度的权重,每个维度对应的权重的取值可视实际需求自定义。
从上面的描述可以看出,调度分的打分机制融合了控制端的考虑(运营策略得分),客户端的考虑(互动性得分),服务端的考虑(新鲜度得分),平台生态的考虑(价格得分,预估点击率得分),调度分越高的社交服务端,将具有越高的推送优先级,以此来控制消息的推送,可以使消息的推送更精准,更具针对性。
(3)第二确定单元403;
第二确定单元403,用于根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端。
为避免推送消息过多给用户造成骚扰,可以为社交客户端设置接收频次上限,即设置社交客户端在预设时间长度内可接收推送消息的数量上限,如果在未来某个时间段内,各个社交服务端将要推送给某个社交客户端的消息的数量之和,大于该社交客户端在该时间段内可接收消息的数量上限时,则各个社交服务端之间需要竞争消息推送权,则第二确定单元403需要确定具有消息推送权的社交服务端。
具体在本实施例中,第二确定单元403可以将先到先得的控制机制与推送优先级结合起来,用于确定具有消息推送权的社交服务端,以避免各个社交服务端之间的不良竞争,即在某个时间段内,已发送消息推送请求,且推送优先级较高的社交服务端,才具有较高赢得消息推送权的概率。
另外,为了兼顾突发性的推送任务,保证推送消息的实时性,控制端可以将社交客户端在某个时间段内的可接收频次均匀随机释放。例如,社交客户端在接下来的一天内有6个可接收频次(即可以接收6条推送消息),那么可以从0点开始,每隔4小时(这个间隔称之为竞争时间区间)随机释放一个可接收频次(即每个竞争时间区间内的可接收消息数量为1),24小时内将释放6个可接收频次,这样各个社交服务端在对应竞争时间区间内只能竞争该竞争时间区间之内的推送频次,而当前竞争时间区间没有被消耗的频次将自动保存到下一竞争时间区间。
具体地,第二确定单元403可以包括选择子单元和确定子单元,其中:
选择子单元用于按照推送优先级从高到低的顺序依次选取预设数量的社交服务端,所述预设数量的取值与所述可接收消息数量的取值相同,本实施例中,可以认为社交服务端每发送一次消息推送请求,就有一条消息要推送给社交客户端,所选取的社交服务端的数量与要推送消息的数量相同;确定子单元,用于确定所述选择子单元所选取的预设数量的社交服务端为具有消息推送权的社交服务端。
(4)发送单元404;
发送单元404,用于将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。
需要说明的是,上述实施例提供的消息推送装置在实现消息推送时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即将设备的内部结构划分成不同的功能模块,以完成以上描述的全部或者部分功能。另外,上述实施例提供的消息推送装置与消息推送方法属于同一构思,其具体实现过程详见方法实施例,此处不再赘述。
本实施例中,在接收单元接收到各个社交服务端发送的针对同一社交客户端的消息推送请求之后,计算单元会根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级,确定单元根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端,发送单元将具有消息推送权的社交服务端的推送消息发送给所述社交客户端,由于在消息推送的过程中,同时考量了社交服务端的得分情况及社交客户端的接收情况,因而能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了社交服务端与社交客户端的相对融合与平衡。
实施例四
本发明实施例还提供一种消息推送装置,如图5所示,其示出了本发明实施例所涉及的装置的结构示意图,具体来讲:
该装置可以包括一个或者一个以上处理核心的处理器501、一个或一个以上计算机可读存储介质的存储器502、射频(Radio Frequency,RF)电路503、电源505、输入单元505、以及显示单元506等部件。本领域技术人员可以理解,图5中示出的装置结构并不构成对装置的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。其中:
处理器501是该装置的控制中心,利用各种接口和线路连接整个装置的各个部分,通过运行或执行存储在存储器502内的软件程序和/或模块,以及调用存储在存储器502内的数据,执行装置的各种功能和处理数据,从而对装置进行整体监控。可选的,处理器501可包括一个或多个处理核心;优选的,处理器501可集成应用处理器和调制解调处理器,其中,应用处理器主要处理操作系统、用户界面和应用程序等,调制解调处理器主要处理无线通信。可以理解的是,上述调制解调处理器也可以不集成到处理器501中。
存储器502可用于存储软件程序以及模块,处理器501通过运行存储在存储器502的软件程序以及模块,从而执行各种功能应用以及数据处理。存储器502可主要包括存储程序区和存储数据区,其中,存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等;存储数据区可存储根据装置的使用所创建的数据等。此外,存储器502可以包括高速随机存取存储器,还可以包括非易失性存储器,例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地,存储器502还可以包括存储器控制器,以提供处理器501对存储器502的访问。
RF电路503可用于收发信息过程中,信号的接收和发送,特别地,将基站的下行信息接收后,交由一个或者一个以上处理器501处理;另外,将涉及上行的数据发送给基站。通常,RF电路503包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、低噪声放大器(LNA,Low Noise Amplifier)、双工器等。此外,RF电路503还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议,包括但不限于全球移动通讯系统(GSM,Global System of Mobilecommunication)、通用分组无线服务(GPRS,General Packet Radio Service)、码分多址(CDMA,Code Division Multiple Access)、宽带码分多址(WCDMA,Wideband CodeDivision Multiple Access)、长期演进(LTE,Long Term Evolution)、电子邮件、短消息服务(SMS,Short Messaging Service)等。
装置还包括给各个部件供电的电源504(比如电池),优选的,电源504可以通过电源管理系统与处理器501逻辑相连,从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源504还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。
该装置还可包括输入单元505,该输入单元505可用于接收输入的数字或字符信息,以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地,在一个具体的实施例中,输入单元505可包括触敏表面以及其他输入设备。触敏表面,也称为触摸显示屏或者触控板,可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面上或在触敏表面附近的操作),并根据预先设定的程式驱动相应的连接装置。可选的,触敏表面可包括触摸检测装置和触摸控制器两个部分。其中,触摸检测装置检测用户的触摸方位,并检测触摸操作带来的信号,将信号传送给触摸控制器;触摸控制器从触摸检测装置上接收触摸信息,并将它转换成触点坐标,再送给处理器501,并能接收处理器501发来的命令并加以执行。此外,可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面。除了触敏表面,输入单元505还可以包括其他输入设备。具体地,其他输入设备可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
该装置还可包括显示单元506,该显示单元506可用于显示由用户输入的信息或提供给用户的信息以及装置的各种图形用户接口,这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元506可包括显示面板,可选的,可以采用液晶显示器(LCD,Liquid Crystal Display)、有机发光二极管(OLED,Organic Light-EmittingDiode)等形式来配置显示面板。进一步的,触敏表面可覆盖显示面板,当触敏表面检测到在其上或附近的触摸操作后,传送给处理器501以确定触摸事件的类型,随后处理器501根据触摸事件的类型在显示面板上提供相应的视觉输出。虽然在图5中,触敏表面与显示面板是作为两个独立的部件来实现输入和输入功能,但是在某些实施例中,可以将触敏表面与显示面板集成而实现输入和输出功能。
尽管未示出,装置还可以包括摄像头、蓝牙模块等,在此不再赘述。具体在本实施例中,装置中的处理器501会按照如下的指令,将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器502中,并由处理器501来运行存储在存储器502中的应用程序,从而实现各种功能,如下:
接收各个社交服务端发送的针对同一社交客户端的消息推送请求;
根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级;
根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端;
将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。
具体地,所述消息推送请求中包含所述社交客户端的标识信息。
具体地,每个社交服务端的多维度特征信息包括下述至少一项:该社交服务端与所述社交客户端之间的互动信息,该社交服务端推送消息的新鲜度,针对该社交服务端设置的运营策略,该社交服务端推送消息的预估点击率,和所述社交客户端对该社交服务端推送消息所涉及的产品的出价。
进一步地,处理器501还用于,
根据所述社交客户端与所述各个社交服务端之间的活跃度及预设对应关系,获取所述各个社交服务端的消息推送上限;
从所述各个社交服务端中,去除消息推送数量已达对应消息推送上限的社交服务端;
根据剩余社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述剩余社交服务端的推送优先级。
具体地,处理器501在如下情形下确定具有消息推送权的社交服务端:
当所述剩余社交服务端推送消息的数量之和,大于所述社交客户端在预设竞争时间区间内的可接收消息数量时,根据所述剩余社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端。
进一步地,所述社交客户端在预设竞争时间区间内的可接收消息数量随机释放。
具体地,处理器01按照如下方式确定具有消息推送权的社交服务端:
从所述剩余社交服务端中,按照推送优先级从高到低的顺序依次选取预设数量的社交服务端,所述预设数量的取值与所述可接收消息数量的取值相同;
确定所选取的预设数量的社交服务端为具有消息推送权的社交服务端。
由上可知,本实施例的装置在接收到各个社交服务端发送的针对同一社交客户端的消息推送请求之后,会根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级,根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次确定具有消息推送权的社交服务端,将具有消息推送权的社交服务端的推送消息发送给所述社交客户端,由于在消息推送的过程中,同时考量了社交服务端的得分情况及社交客户端的接收情况,因而能够避免消息推送过渡骚扰用户,且兼顾了各社交服务端的利益均衡,实现了社交服务端与社交客户端的相对融合与平衡。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,装置,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (14)

1.一种消息推送方法,其特征在于,包括:
接收各个社交服务端发送的针对同一社交客户端的消息推送请求;
根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级;
根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端;
将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。
2.根据权利要求1所述的方法,其特征在于,所述消息推送请求中包含所述社交客户端的标识信息。
3.根据权利要求1所述的方法,其特征在于,每个社交服务端的多维度特征信息包括下述至少一项:该社交服务端与所述社交客户端之间的互动信息,该社交服务端推送消息的新鲜度,针对该社交服务端设置的运营策略,该社交服务端推送消息的预估点击率,和所述社交客户端对该社交服务端推送消息所涉及的产品的出价。
4.根据权利要求1至3任意一项所述的方法,其特征在于,在根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级之前,所述方法还包括:
根据所述社交客户端与所述各个社交服务端之间的活跃度及预设对应关系,获取所述各个社交服务端的消息推送上限;
从所述各个社交服务端中,去除消息推送数量已达对应消息推送上限的社交服务端;
根据剩余社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述剩余社交服务端的推送优先级。
5.根据权利要求4所述的方法,其特征在于,所述根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端包括:
当所述剩余社交服务端推送消息的数量之和,大于所述社交客户端在预设竞争时间区间内的可接收消息数量时,根据所述剩余社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端。
6.根据权利要求5所述的方法,其特征在于,所述社交客户端在预设竞争时间区间内的可接收消息数量随机释放。
7.根据权利要求5所述的方法,其特征在于,所述根据所述剩余社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端包括:
从所述剩余社交服务端中,按照推送优先级从高到低的顺序依次选取预设数量的社交服务端,所述预设数量的取值与所述可接收消息数量的取值相同;
确定所选取的预设数量的社交服务端为具有消息推送权的社交服务端。
8.一种消息推送装置,其特征在于,包括:
接收单元,用于接收各个社交服务端发送的针对同一社交客户端的消息推送请求;
第一确定单元,用于根据所述各个社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述各个社交服务端的推送优先级;
第二确定单元,用于根据所述各个社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端;
发送单元,用于将具有消息推送权的社交服务端的推送消息发送给所述社交客户端。
9.根据权利要求8所述的装置,其特征在于,所述接收单元接收到的所述各个社交服务端发送的消息推送请求中均包含所述社交客户端的标识信息。
10.根据权利要求8所述的装置,其特征在于,每个社交服务端的多维度特征信息包括下述至少一项:该社交服务端与所述社交客户端之间的互动信息,该社交服务端推送消息的新鲜度,针对该社交服务端设置的运营策略,该社交服务端推送消息的预估点击率,和所述社交客户端对该社交服务端推送消息所涉及的产品的出价。
11.根据权利要求8至11任意一项所述的装置,其特征在于,所述装置还包括:
获取单元,用于根据所述社交客户端与所述各个社交服务端之间的活跃度及预设对应关系,获取所述各个社交服务端的消息推送上限;
去除单元,用于从所述各个社交服务端中,去除消息推送数量已达对应消息推送上限的社交服务端。
所述第一确定单元具体用于,根据剩余社交服务端在社交服务端、控制端及社交客户端的多维度特征信息确定所述剩余社交服务端的推送优先级。
12.根据权利要求11所述的装置,其特征在于,所述第二确定单元具体用于,
在所述剩余社交服务端推送消息的数量之和,大于所述社交客户端在预设竞争时间区间内的可接收消息数量时,根据所述剩余社交服务端的推送优先级,以及所述社交客户端的可接收频次,确定具有消息推送权的社交服务端。
13.根据权利要求12所述的装置,其特征在于,所述社交客户端在预设竞争时间区间内的可接收消息数量随机释放。
14.根据权利要求12所述的装置,其特征在于,所述第二确定单元包括:
选择子单元,用于从所述剩余社交服务端中,按照推送优先级从高到低的顺序依次选取预设数量的社交服务端,所述预设数量的取值与所述可接收消息数量的取值相同;
确定子单元,用于确定所述选择子单元所选取的预设数量的社交服务端为具有消息推送权的社交服务端。
CN201610945481.2A 2016-10-26 2016-10-26 一种消息推送方法及装置 Active CN106453593B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610945481.2A CN106453593B (zh) 2016-10-26 2016-10-26 一种消息推送方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610945481.2A CN106453593B (zh) 2016-10-26 2016-10-26 一种消息推送方法及装置

Publications (2)

Publication Number Publication Date
CN106453593A true CN106453593A (zh) 2017-02-22
CN106453593B CN106453593B (zh) 2020-09-04

Family

ID=58178425

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610945481.2A Active CN106453593B (zh) 2016-10-26 2016-10-26 一种消息推送方法及装置

Country Status (1)

Country Link
CN (1) CN106453593B (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108400927A (zh) * 2018-01-22 2018-08-14 广州欧赛斯信息科技有限公司 一种针对高并发消息的消息推送方法及装置
CN109862057A (zh) * 2017-11-30 2019-06-07 北京嘀嘀无限科技发展有限公司 运营推送方法、装置、服务器和计算机可读存储介质
CN110708360A (zh) * 2019-09-17 2020-01-17 Oppo广东移动通信有限公司 一种信息处理方法、系统和电子设备
CN110719308A (zh) * 2018-07-12 2020-01-21 深圳市于易点科技有限公司 一种规避高并发消息阻塞的方法和系统
CN112637291A (zh) * 2020-12-14 2021-04-09 北京健康之家科技有限公司 基于公共平台推送信息的方法、装置、存储介质及设备

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101647282A (zh) * 2007-03-30 2010-02-10 汤姆森许可贸易公司 用于移动tv的鲁棒文件传播
CN101986657A (zh) * 2010-10-28 2011-03-16 浙江大学 基于移动widget定向推送特定服务的方法
CN102546605A (zh) * 2011-12-22 2012-07-04 北京锐讯灵通科技有限公司 移动应用推广系统及方法
US20130346521A1 (en) * 2012-06-22 2013-12-26 Salesforce.Com, Inc. Methods and systems for priority-based notifications for mobile devices
CN104980898A (zh) * 2014-04-04 2015-10-14 中兴通讯股份有限公司 一种信息推送方法、系统及设备
CN105068869A (zh) * 2015-09-29 2015-11-18 北京网诺星云科技有限公司 在移动终端中的信息推送的方法及装置
CN105610886A (zh) * 2014-11-25 2016-05-25 腾讯科技(深圳)有限公司 信息推送的控制方法及信息推送平台
CN105847020A (zh) * 2016-05-18 2016-08-10 腾讯科技(深圳)有限公司 消息推送方法和装置
CN105991407A (zh) * 2015-02-12 2016-10-05 腾讯科技(深圳)有限公司 一种消息处理方法、装置及处理服务器
CN105991408A (zh) * 2015-02-12 2016-10-05 腾讯科技(深圳)有限公司 一种消息处理方法、装置及处理服务器

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101647282A (zh) * 2007-03-30 2010-02-10 汤姆森许可贸易公司 用于移动tv的鲁棒文件传播
CN101986657A (zh) * 2010-10-28 2011-03-16 浙江大学 基于移动widget定向推送特定服务的方法
CN102546605A (zh) * 2011-12-22 2012-07-04 北京锐讯灵通科技有限公司 移动应用推广系统及方法
US20130346521A1 (en) * 2012-06-22 2013-12-26 Salesforce.Com, Inc. Methods and systems for priority-based notifications for mobile devices
CN104980898A (zh) * 2014-04-04 2015-10-14 中兴通讯股份有限公司 一种信息推送方法、系统及设备
CN105610886A (zh) * 2014-11-25 2016-05-25 腾讯科技(深圳)有限公司 信息推送的控制方法及信息推送平台
CN105991407A (zh) * 2015-02-12 2016-10-05 腾讯科技(深圳)有限公司 一种消息处理方法、装置及处理服务器
CN105991408A (zh) * 2015-02-12 2016-10-05 腾讯科技(深圳)有限公司 一种消息处理方法、装置及处理服务器
CN105068869A (zh) * 2015-09-29 2015-11-18 北京网诺星云科技有限公司 在移动终端中的信息推送的方法及装置
CN105847020A (zh) * 2016-05-18 2016-08-10 腾讯科技(深圳)有限公司 消息推送方法和装置

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109862057A (zh) * 2017-11-30 2019-06-07 北京嘀嘀无限科技发展有限公司 运营推送方法、装置、服务器和计算机可读存储介质
CN108400927A (zh) * 2018-01-22 2018-08-14 广州欧赛斯信息科技有限公司 一种针对高并发消息的消息推送方法及装置
CN108400927B (zh) * 2018-01-22 2021-01-26 广州欧赛斯信息科技有限公司 一种针对高并发消息的消息推送方法及装置
CN110719308A (zh) * 2018-07-12 2020-01-21 深圳市于易点科技有限公司 一种规避高并发消息阻塞的方法和系统
CN110708360A (zh) * 2019-09-17 2020-01-17 Oppo广东移动通信有限公司 一种信息处理方法、系统和电子设备
CN112637291A (zh) * 2020-12-14 2021-04-09 北京健康之家科技有限公司 基于公共平台推送信息的方法、装置、存储介质及设备

Also Published As

Publication number Publication date
CN106453593B (zh) 2020-09-04

Similar Documents

Publication Publication Date Title
CN106453593A (zh) 一种消息推送方法及装置
CN106097057B (zh) 一种虚拟物品发放方法及装置
CN106899457B (zh) 一种监测应用在线时长的方法及服务器
CN108470253A (zh) 一种用户识别方法、装置及存储设备
CN109117958A (zh) 便携式电子设备估价方法、回收方法、终端、云端及系统
CN108334887A (zh) 一种用户选取方法和装置
CN105833526B (zh) 一种游戏数据的处理方法和系统
US11240777B2 (en) Device positioning method and apparatus
KR20180067619A (ko) 정보 푸싱 방법, 디바이스 및 시스템과 컴퓨터 저장 매체
CN104063410A (zh) 一种举报信息的处理方法和系统
CN104519262A (zh) 获取视频数据的方法、装置及终端
CN107291317A (zh) 一种虚拟场景中目标的选择方法和装置
CN107437189A (zh) 一种推广信息的投放方法、装置及系统
CN106502783A (zh) 一种内存管理方法及终端设备
CN104994080A (zh) 信息处理方法、系统及电子设备
CN111625690B (zh) 一种对象推荐方法、装置、设备及介质
CN106453840A (zh) 移动终端的性能调整方法及移动终端
CN104978353A (zh) 一种桌面应用的生成控制方法、装置及系统
CN106899929A (zh) 一种信号搜索方法、装置和系统
CN108492213A (zh) 食材购买清单的生成方法及装置、服务器设备、存储介质
CN106303589B (zh) 一种直播控制方法及装置
CN103413379B (zh) 一种充值方法、终端和充值卡
CN106330681A (zh) 一种共享观影信息的方法、系统及相关设备
CN104967648B (zh) 一种网际协议地址的调度方法、装置和系统
CN105208276B (zh) 移动终端的拍照方法及装置

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant