用户推荐方法及装置与流程

本申请涉及互联网技术领域，尤其涉及用户推荐方法及装置。

背景技术：

在相关技术中，为用户提供了交互平台，则任意用户之间均可以通过该交互平台执行相应的对象交互。由于只能够在交互平台上对交互对象进行在线浏览，因而用户之间可能针对交互对象进行在线通信，以进一步确认交互对象的情况。

技术实现要素：

有鉴于此，本申请提供一种用户推荐方法及装置，可以实现交互用户之间的匹配，有助于提升交互效率。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种用户推荐方法，包括：

检测到针对任一交互对象的浏览事件；

获取所述任一交互对象的处于可通信状态的提供方用户；

将所述提供方用户的信息推荐至所述浏览事件的发起方用户，以使所述发起方用户向所述提供方用户发起针对所述任一交互对象的通信事件。

根据本申请的第二方面，提出了一种用户推荐装置，包括：

检测单元，检测到针对任一交互对象的浏览事件；

获取单元，获取所述任一交互对象的处于可通信状态的提供方用户；

推荐单元，将所述提供方用户的信息推荐至所述浏览事件的发起方用户， 以使所述发起方用户向所述提供方用户发起针对所述任一交互对象的通信事件。

由以上技术方案可见，本申请通过检测发起方用户当前浏览的交互对象，可以获取相应的提供方用户，并且向发起方用户推荐处于可通信状态的提供方用户，从而确保发起方用户可以与相应的提供方用户进行在线通信，以充分了解交互对象的信息，有助于提升针对交互对象的交互效率。

附图说明

图1是根据本申请一示例性实施例提供的一种用户推荐方法的流程图；

图2是根据本申请一示例性实施例提供的一种应用场景的示意图；

图3是根据本申请一示例性实施例提供的另一种用户推荐方法的流程图；

图4是根据本申请一示例性实施例提供的又一种用户推荐方法的流程图；

图5是根据本申请一示例性实施例提供的又一种用户推荐方法的流程图；

图6是根据本申请一示例性实施例提供的又一种用户推荐方法的流程图；

图7是根据本申请一示例性实施例提供的一种电子设备的结构示意图；

图8是根据本申请一示例性实施例提供的一种用户推荐装置的框图。

具体实施方式

基于交互平台，用户之间可以实现在线的对象交互；而当用户需要进一步了解交互对象的情况时，显然需要确保双方用户均处于可通信状态，才能够保证一方用户可以向另一方用户在线查询关于交互对象的情况。

然而，在一种情况下，相关技术中的交互平台并不提供每个用户的状态信息，即任一用户无法了解到另一用户是否处于可通信状态，则用户很可能在一番浏览之后，发现提供方用户并不处于可通信状态；在另一种情况下，相关技术中的交互平台中提供了每个用户的状态信息，但用户在浏览过程中首先关注的往往是交互对象本身，因而花费大量时间来查看交互平台中提供的对交互对象的描述信息，然后才可能需要与提供方用户进行通信交流，但 提供方用户很可能处于非可通信状态。

可见，在相关技术中的技术方案中，用户往往会浪费大量时间，仍然无法有效了解交互对象的情况，造成对象交互的效率很低。

因此，本申请通过对提供方用户的智能推荐，可以避免相关技术中存在的上述不足。为对本申请进行进一步说明，提供下列实施例：

图1是根据本申请一示例性实施例提供的一种用户推荐方法的流程图，如图1所示，该方法应用于交互平台的服务器中，可以包括以下步骤：

步骤102，检测到针对任一交互对象的浏览事件。

在本实施例中，浏览事件的发起方用户通过终端设备进行页面浏览，当被浏览页面中包含交互对象时，可以认为发起方用户发起了针对该被浏览页面中的任一交互对象的浏览事件。

在本实施例中，交互平台可以用于任一类型的交互对象的交互操作，本申请并不对此进行限制。举例而言，该交互平台可以为网络交易平台，则交互对象可以为该网络交易平台中的交易货品，而发起方用户为交易货品的买方用户、提供方用户为该交易货品的卖方用户。

步骤104，获取所述任一交互对象的处于可通信状态的提供方用户。

在本实施例中，交互平台上的同一交互对象可能存在很多提供方用户，则通过对每个提供方用户的状态检测，即可获取处于可通信状态的提供方用户。比如在提供方用户在交互平台上的账号处于登录状态，或者提供方用户在预设时间内存在针对交互平台的操作等情况下，可以认为该提供方用户处于可通信状态；或者，由于可能存在跨时区的全球交互，则可以获取提供方用户所处的时区，当该时区处于可用状态(即当地时间为工作时间，比如早上8点至晚上12点之间)时，判定该提供方用户处于可通信状态。

步骤106，将所述提供方用户的信息推荐至所述浏览事件的发起方用户，以使所述发起方用户向所述提供方用户发起针对所述任一交互对象的通信事件。

在本实施例中，发起方用户与提供方用户可以通过任意方式建立通信事 件；举例而言，通信事件可以采用即时通信IM(Instant Messaging)实现，但本申请并不对此进行限制。

在本实施例中，交互平台可以与通信系统之间存在预关联，从而由交互平台直接唤起通信系统，帮助发起方用户与提供方用户之间建立通信事件，有助于提升通信效率、简化用户操作。具体地，可以由交互平台向通信系统发送关于所述发起方用户和所述处于可通信状态的提供方用户通信请求，以由所述通信系统在所述发起方用户和所述处于可通信状态的提供方用户之间建立所述通信事件。

由以上技术方案可见，本申请通过检测发起方用户当前浏览的交互对象，可以获取相应的提供方用户，并且向发起方用户推荐处于可通信状态的提供方用户，从而确保发起方用户可以与相应的提供方用户进行在线通信，以充分了解交互对象的信息，有助于提升针对交互对象的交互效率。

图2是根据本申请一示例性实施例提供的一种应用场景的示意图，如图2所示，由服务器承载交互平台的运行和各个处理功能，而用户通过终端连接至服务器后，可以访问交互平台，从而在交互平台上提供交互对象或浏览其他用户提供的交互对象。终端可以为移动设备(比如终端1、终端2为智能手机)或非移动设备(比如终端3为个人计算机)，本申请并不对此进行限制。当用户之间需要进行对象交互或通信时，需要在终端上登录预先注册的账号，以使交互平台和其他用户了解自己的身份信息等。

为便于说明，下面以交互平台为“网络交易平台”为例，结合图3-6对交互平台以及本申请的技术方案进行详细描述。

实施例一

图3是根据本申请一示例性实施例提供的另一种用户推荐方法的流程图，如图3所示，该方法可以包括以下步骤：

步骤302，服务器检测到买家用户发起对交易货品的浏览事件。

在本实施例中，当交互平台为网络交易平台时，交易货品为该平台中的交互对象，该交易货品可以为实体物品或虚拟物品。当买家用户通过终端浏 览网络交易平台时，浏览事件针对当前浏览页面内的所有交易货品而被检测；比如，当前浏览页面可以为搜索结果展示页面、详情展示页面、货品推荐页面等。其中，可以通过预先设定，仅针对特定类型的页面或交易货品进行浏览事件的检测，比如仅对详情展示页面进行检测、仅对未购买过的交易货品(即未交互过的交互对象)进行检测等。

步骤304，判断交互对象所属的卖家用户是否处于可通信状态，若处于可通信状态则返回步骤302，否则转入步骤306。

在本实施例中，可以通过多种方式判断卖家用户的实时状态。比如当卖家用户在网络交易平台上登录了自己的注册账号时，或者检测到卖家用户在预设时间段内(比如3分钟内)的任意操作时，说明卖家用户很可能处于终端旁边，并判定卖家用户处于可通信状态，否则判定卖家用户处于非可通信状态。

步骤306，从可提供被浏览的交易货品的所有卖家用户中，获取处于可通信状态的卖家用户。

在本实施例中，确定浏览事件针对的任一交互对象(即被浏览的交易货品)的所属用户；当所述所属用户处于非可通信状态时，获取所述任一交互对象的处于可通信状态的提供方用户(即卖家用户)。

通过选取处于可通信状态的卖家用户，使得买家用户可以与这些卖家用户进行实时通信，及时了解被浏览的交易货品的任意情况；同时，避免买家用户对某个卖家用户的交易货品进行长时间浏览后，才发现该卖家用户处于非可通信状态，而不得不重新寻找其他卖家用户，有助于提升浏览和交易效率。

步骤308，向发起浏览事件的买家用户推荐所有的卖家用户。

在本实施例中，可以在终端屏幕上的任意位置展示推荐的卖家用户；比如在被浏览的交易货品的关联区域(例如四周)内，从而便于买家用户在被浏览的交易货品与推荐的卖家用户之间建立有效的视觉关联。

步骤310，根据买家用户的选择指令，选取至少一个卖家用户。

在本实施例中，由买家用户自行选取卖家用户，从而有助于直接体现出买家用户的兴趣和需求。

步骤312，在买家用户与被选中的卖家用户之间建立通信事件。

在步骤308-312中，服务器将所有处于可通信状态的提供方用户均推荐至所述发起方用户；根据所述发起方用户输入的选择指令，在推荐的所有提供方用户中选择对应的提供方用户；在所述发起方用户与被选中的提供方用户之间建立针对所述任一交互对象的通信事件。

在本实施例中，可以建立“买家用户——服务器——卖家用户”的通信链接，从而由服务器对买家用户和卖家用户之间的通信消息进行转发，以确保通信安全性和稳定性，还可以由服务器对通信消息进行敏感词过滤、病毒防护等处理；或者，可以由服务器将买家用户和卖家用户的通信属性告知对方，从而建立起“买家用户——卖家用户”的通信链接，从而由买家用户与卖家用户之间直接传送通信消息，以降低服务器的运行负担。

实施例二

图4是根据本申请一示例性实施例提供的又一种用户推荐方法的流程图。如图4所示，该方法可以包括以下步骤：

步骤402-406与图3所示的步骤302-306相同，此处不再赘述。

步骤408，服务器向卖家用户发起交互通知。

在本实施例中，虽然服务器可以获取卖家用户是否处于可通信状态，但卖家用户实际上有可能并不处于可通信状态，或者处于可通信状态的卖家用户可能并不希望执行交易(比如被浏览的交易货品当前无货等)，因而可以通过发起交互通知的方式，确定相应的卖家用户的实际情况和意愿。

其中，交互通知中可以包含被浏览的交易货品、买家用户的信息等；当然，买家用户的信息可以仅为诸如“所在地”等信息，而并不包含如姓名、联系方式等信息，以避免买家用户受到骚扰。

步骤410，服务器接收卖家用户的响应消息。

在本实施例中，当接收到响应消息时，表明卖家用户存在相应的交易意 图，且买家用户可以与该卖家用户之间进行通信，以帮助买家用户进一步了解被浏览的交易货品。

步骤412，根据响应消息的接收情况，确定最适合的卖家用户。

步骤414，将最适合的卖家用户推荐至买家用户。

在本实施例中，分别向每个处于可通信状态的提供方用户发送关于所述浏览事件的交互通知；根据每个处于可通信状态的提供方用户对所述交互通知的响应情况，将最适合的提供方用户推荐至所述发起方用户。通过智能选取最适合的卖家用户，可以简化买家用户操作、避免买家用户的自主选择，有助于提升处理效率。

其中，作为一示例性实施方式，最适合的卖家用户可以为最先回复响应消息的卖家用户。

步骤416，在买家用户与卖家用户之间建立通信事件。该步骤与图3所示的步骤312相同，此处不再赘述。

在图4所示的实施例二的基础上，还可以结合买家用户的实际情况，对用户推荐过程进行优化，从而得到下述的实施例三和实施例四。

实施例三

图5是根据本申请一示例性实施例提供的又一种用户推荐方法的流程图。如图5所示，该方法在图4所示实施例的基础上，还可以包括：

步骤40A，获取买家用户的特征描述信息。

在本实施例中，特征描述信息可以包括以下至少之一：买家用户(即发起方用户)的身份信息(譬如姓名、年龄、性别、家庭住址等)、买家用户的行为信息(譬如实时浏览内容等)、买家用户的历史交互信息(譬如历史上购买过的交易货品等)、买家用户的历史浏览信息(譬如历史上浏览过的交易货品等)；当然，任意能够表现出买家用户的特征的信息均可以应用于本申请的技术方案中，本申请并不对此进行限制。

基于步骤40A，则步骤412中，服务器根据每个处于可通信状态的提供方用户对所述交互通知的响应情况，以及每个处于可通信状态的提供方用户 与所述特征描述信息之间的匹配情况，将最适合的提供方用户推荐至所述发起方用户。其中，作为一示例性实施方式，最适合的提供方用户为：完成对所述交互通知的响应且匹配于所述特征描述信息的提供方用户。

通过基于响应情况和匹配情况来选取最适合的卖家用户，使得到的卖家用户同时符合交易双方的需求，从而有助于提升双方用户的使用体验，并使交易更容易成功。

实施例四

图6是根据本申请一示例性实施例提供的又一种用户推荐方法的流程图。如图6所示，该方法可以包括以下步骤：

步骤40B，获取买家用户的特征描述信息；该步骤与图5所示的步骤40A相同，此处不再赘述。

基于步骤40B，则在步骤408中，服务器向与特征描述信息相匹配的每个处于可通信状态的提供方用户分别发送所述交互通知。其中，最适合的提供方用户为：最先响应所述交互通知的提供方用户。

在该实施例中，通过对卖家用户执行基于匹配情况的筛选，使得接收到交互通知的卖家用户均符合买家用户的实际需求，而避免向不匹配的卖家用户发送交互通知，则既能够避免对这些卖家用户的干扰(交互通知对这些卖家用户而言没有意义，实际上是对这些卖家用户的骚扰)，又能够防止向买家用户推荐不适合的卖家用户，使得用户推荐操作更具有针对性。

图7示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图7，在硬件层面，该电子设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成用户推荐装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图8，在软件实施方式中，该用户推荐装置可以包括检测单元、 获取单元和推荐单元。其中：

检测单元，检测到针对任一交互对象的浏览事件；

获取单元，获取所述任一交互对象的处于可通信状态的提供方用户；

推荐单元，将所述提供方用户的信息推荐至所述浏览事件的发起方用户，以使所述发起方用户向所述提供方用户发起针对所述任一交互对象的通信事件。

可选的，所述获取单元具体用于：

确定所述浏览事件针对的所述任一交互对象的所属用户；

当所述所属用户处于非可通信状态时，获取所述任一交互对象的处于可通信状态的提供方用户。

可选的，还包括：

选择单元，在所述推荐单元将所有处于可通信状态的提供方用户推荐至所述发起方用户时，根据所述发起方用户输入的选择指令，在推荐的所有提供方用户中选择对应的提供方用户；

建立单元，在所述发起方用户与被选中的提供方用户之间建立针对所述任一交互对象的通信事件。

可选的，还包括：

通知单元，分别向每个处于可通信状态的提供方用户发送关于所述浏览事件的交互通知；

其中，所述推荐单元根据每个处于可通信状态的提供方用户对所述交互通知的响应情况，将最适合的提供方用户推荐至所述发起方用户。

可选的，还包括：

信息获取单元，获取所述发起方用户的特征描述信息；

其中，所述推荐单元根据每个处于可通信状态的提供方用户对所述交互通知的响应情况，以及每个处于可通信状态的提供方用户与所述特征描述信息之间的匹配情况，将最适合的提供方用户推荐至所述发起方用户。

可选的，所述最适合的提供方用户为：完成对所述交互通知的响应且匹 配于所述特征描述信息的提供方用户。

可选的，所述通知单元具体用于：

获取所述发起方用户的特征描述信息；

向与所述特征描述信息相匹配的每个处于可通信状态的提供方用户分别发送所述交互通知。

可选的，所述最适合的提供方用户为：最先响应所述交互通知的提供方用户。

可选的，所述特征描述信息包括以下至少之一：所述发起方用户的身份信息、所述发起方用户的行为信息、所述发起方用户的历史交互信息、所述发起方用户的历史浏览信息。

可选的，所述任一交互对象为任一商品，所述提供方用户为卖家用户、所述发起方用户为买家用户。

可选的，所述通信事件采用即时通信IM实现。

可选的，还包括：

请求单元，向通信系统发送关于所述发起方用户和所述处于可通信状态的提供方用户通信请求，以由所述通信系统在所述发起方用户和所述处于可通信状态的提供方用户之间建立所述通信事件。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程 只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。