CN113779416A - 信息推荐方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请提供了一种信息推荐方法、装置、电子设备及计算机可读存储介质，应用于互联网和智慧交通领域；方法包括：接收客户端发送的针对目标对象的信息请求；其中，信息请求是客户端被刷新时发送的；基于信息请求携带的历史刷新数据以及已应用版本进行查询操作，得到待应用运营策略中针对从刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息；获取与目标对象的特征适配的推荐信息流；向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息，以供客户端进行刷新显示。通过本申请，能够实现不同运营信息在推荐信息流中的灵活插入。

Description

信息推荐方法、装置、电子设备及计算机可读存储介质

技术领域

本申请涉及互联网和智慧交通技术领域，尤其涉及一种信息推荐方法、装置、电子设备及计算机可读存储介质。

背景技术

互联网特别是移动互联网的普及，使得信息推荐成为获取信息的重要途径。推荐信息流是内容生产方提供的，同时，个性化推荐是人工智能的一个重要应用，其目的在于向对象（例如用户）推荐感兴趣的内容，例如推荐系统可以基于用户的兴趣（例如美食、游戏、电影、运动等）和行为（例如点赞、收藏、评论、转发等）选出合适的推荐信息提供给用户进行浏览。此外，运营方可以在推荐信息流中插入广告、热点内容、公益信息等运营信息，从而丰富用户观看的信息。

然而，相关技术在推荐信息流中插入运营信息的方式单一，无法适应运营方插入运营信息时快速迭代的需求。

发明内容

本申请实施例提供一种信息推荐方法、装置、电子设备、计算机可读存储介质及计算机程序产品，能够实现不同运营信息在推荐信息流中的灵活插入。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种信息推荐方法，包括：

接收客户端发送的针对目标对象的信息请求；其中，所述信息请求是所述客户端被刷新时发送的，且携带所述客户端的历史刷新数据以及已应用版本，所述已应用版本是所述客户端中应用的运营策略的版本；

基于所述历史刷新数据以及所述已应用版本进行查询操作，得到待应用运营策略中针对从所述刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息；

获取与所述目标对象的特征适配的推荐信息流；

向所述客户端发送所述推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息，以供所述客户端进行刷新显示。

本申请实施例提供一种信息推荐装置，包括：

接收模块，用于接收客户端发送的针对目标对象的信息请求；其中，所述信息请求是所述客户端被刷新时发送的，且携带所述客户端的历史刷新数据以及已应用版本，所述已应用版本是所述客户端中应用的运营策略的版本；

查询模块，用于基于所述历史刷新数据以及所述已应用版本进行查询操作，得到待应用运营策略中针对从所述刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息；

获取模块，用于获取与所述目标对象的特征适配的推荐信息流；

发送模块，用于向所述客户端发送所述推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息，以供所述客户端进行刷新显示。

本申请实施例提供一种信息推荐方法，包括：

响应于客户端被刷新，显示推荐信息流；

在所述推荐信息流中插入至少一个展示位置，并在插入的每个所述展示位置中显示对应配置的运营信息；

其中，针对多次所述刷新分别插入的至少一个展示位置，用于循环显示对应配置的运营信息，或者，在展示一遍对应配置的运营信息后隐藏。

本申请实施例提供一种信息推荐装置，包括：

显示模块，用于响应于客户端被刷新，显示推荐信息流；

插入模块，用于在所述推荐信息流中插入至少一个展示位置；

所述显示模块，还用于在插入的每个所述展示位置中显示对应配置的运营信息；

其中，针对多次所述刷新分别插入的至少一个展示位置，用于循环显示对应配置的运营信息，或者，在展示一遍对应配置的运营信息后隐藏。

本申请实施例提供一种电子设备，包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的信息推荐方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现本申请实施例提供的信息推荐方法。

本申请实施例提供一种计算机程序产品，包括计算机程序或指令，用于引起处理器执行时，实现本申请实施例提供的信息推荐方法。

本申请实施例具有以下有益效果：

通过设置运营策略的版本与运营方的不断变化的需求同步，即通过每个版本的运营策略对不同运营信息在推荐信息流中的插入进行了位置粒度的配置，在每次刷新客户端时，按照不同版本的运营策略进行运营信息的插入，从而满足了运营方在推荐信息流中插入运营信息时不断变化的需求。

附图说明

图1是本申请实施例提供的信息推荐系统100的架构示意图；

图2是本申请实施例提供的服务器200的结构示意图；

图3是本申请实施例提供的终端设备400的结构示意图；

图4是本申请实施例提供的信息推荐方法的流程示意图；

图5是本申请实施例提供的获取推荐信息流的原理示例图；

图6A是本申请实施例提供的信息推荐方法的流程示意图一；

图6B是本申请实施例提供的信息推荐方法的流程示意图二；

图7是本申请实施例提供的信息推荐方法的应用场景示意图；

图8是本申请实施例提供的信息推荐系统的架构示意图；

图9是本申请实施例提供的曝光策略的示意图；

图10是本申请实施例提供的必出策略的示意图；

图11是本申请实施例提供的客户端存储示意图；

图12是本申请实施例提供的针对失效信息进行删除的示意图；

图13是本申请实施例提供的基于特征过滤平台进行用户请求分组的示意图；

图14是本申请实施例提供的基于特征过滤平台对业务串进行匹配的示意图；

图15是本申请实施例提供的业务后台的本地缓存示意图；

图16是本申请实施例提供的在推荐信息流中插入运营信息的示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1）响应于：用于表示所执行的操作所依赖的条件或者状态，当满足所依赖的条件或状态时，所执行的一个或多个操作可以是实时的，也可以具有设定的延迟；在没有特别说明的情况下，所执行的多个操作不存在执行先后顺序的限制。

2）客户端：终端设备中呈现推荐信息流的应用程序，例如即时通信客户端、社交媒体客户端、资讯类阅读客户端、浏览器等。

3）运营信息：指运营人员在运营策略配置平台中配置的时下的热点内容、广告、或者希望宣传的相关内容等，用于插入到推荐信息流中，以达到丰富推荐信息流的效果，进而达到提高用户观看量、以及增加用户留存率等目的。

4）推荐信息：基于用户的兴趣（例如美食、游戏、电影、运动等）和行为（例如点赞、收藏、评论、转发等）进行离线或者用户请求时在线计算得到的内容，即推荐信息是符合用户偏好的内容。

5）刷新次数：简称刷次，指客户端接收的针对推荐信息流的刷新操作的次数，客户端在每次接收到用户触发的刷新操作时，均会向服务器请求新的推荐信息流，即用户每触发一次刷新操作，服务器会向客户端发送最新的推荐信息流。

本申请实施例提供一种信息推荐方法、装置、电子设备、计算机可读存储介质及计算机程序产品，能够实现不同运营信息在推荐信息流中的灵活插入。下面说明本申请实施例提供的电子设备的示例性应用，本申请实施例提供的电子设备可以实施为笔记本电脑，平板电脑，台式计算机，机顶盒，移动设备（例如，移动电话，便携式音乐播放器，个人数字助理，专用消息设备，便携式游戏设备），车载终端等各种类型的终端设备，也可以实施为服务器，或者由终端设备和服务器协同实施。下面，将以终端设备和服务器协同实施本申请实施例提供的信息推荐方法为例进行说明。

参见图1，图1是本申请实施例提供的信息推荐系统100的架构示意图，为实现支撑一个在推荐信息流中灵活插入不同运营信息的应用，终端设备400通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合。

如图1所示，终端设备400上运行有客户端410，客户端410可以是各种类型的客户端，例如即时通信客户端、社交媒体客户端、资讯类阅读客户端、浏览器等，响应于针对客户端410的刷新（例如客户端410接收到用户触发的下拉刷新操作或者接收到用户针对刷新按钮的触发操作），通过网络300向服务器200发送针对目标对象（例如用户A）的信息（包括推荐信息和运营信息）请求；其中，信息请求中携带用于供服务器200进行查询操作的客户端410的历史刷新数据以及已应用版本（即客户端410中当前应用的运营策略的版本）。

服务器200在接收到客户端410发送的信息请求之后，从信息请求中解析出携带的历史刷新数据以及已应用版本，并基于解析得到的历史刷新数据以及已应用版本进行查询操作（例如假设每个版本的运营策略是以多刷多展示位置配置数据的形式存储在独立于服务器200部署的数据库500中的，则服务器200可以基于历史刷新数据以及已应用版本在数据库500中进行查询；当然，每个版本的运营策略也可以是存储在服务器200的多刷多展示位置缓存中的，则当数据库500无法被访问时，服务器200还可以基于历史刷新数据以及已应用版本在服务器200自身的多刷多展示位置缓存中进行查询），得到待应用运营策略中针对从刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息，接着服务器200还可以从推荐信息库（图1中未示出）中获取与用户A的特征适配的推荐信息流，随后服务器200可以向客户端410发送所获取的推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息。

客户端410在接收到服务器200返回的推荐信息流、针对从刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对配置的每个展示位置所配置的运营信息之后，在人机交互界面中显示推荐信息流，在推荐信息流中插入针对刷新所配置的至少一个展示位置，在插入的每个展示位置中显示对应配置的运营信息，如此，能够实现不同运营信息在推荐信息流中灵活且高效地插入。

在一些实施例中，本申请实施例可以借助于云技术（Cloud Technology）实现，云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。

云技术是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、以及应用技术等的总称，可以组成资源池，按需所用，灵活便利。云计算技术将变成重要支撑。技术网络系统的后台服务需要大量的计算、存储资源。

示例的，图1中示出的服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络（CDN，ContentDelivery Network）、以及大数据和人工智能平台等基础云计算服务的云服务器。终端设备400可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端设备400以及服务器200可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例中不做限制。

在另一些实施例中，终端设备或服务器还可以通过运行计算机程序来实现本申请实施例提供的信息推荐方法。举例来说，计算机程序可以是操作系统中的原生程序或软件模块，例如，可以嵌入到任意程序中的信息推荐模块；还可以是本地（Native）应用程序（APP，Application），即需要在操作系统中安装才能运行的程序，例如图1中示出的客户端410。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。

在一些实施例中，本申请实施例提供的信息推荐方法还可以应用于智慧交通领域，例如当车载终端对应的后台服务器向用户的车载终端返回推荐信息流（例如新闻资讯、公众号文章等）时，可以调用本申请实施例提供的信息推荐方法在推荐信息流中灵活地插入不同的运营信息（例如交通信息），从而能够丰富推荐信息流的内容，同时也便于用户及时了解交通情况；此外，对于导航场景来说，当服务器向用户的车载终端返回地图数据时，还可以在地图数据中插入周边相关服务的运营信息，以使车载终端在调用导航应用APP的人机交互界面呈现地图的同时，在地图中显示定位周边相关服务的运营信息，从而方便用户了解周边的相关服务。

下面对图1中示出的服务器200的结构进行说明。参见图2，图2是本申请实施例提供的服务器200的结构示意图，图2所示的服务器200包括：至少一个处理器210、存储器240、至少一个网络接口220。服务器200中的各个组件通过总线系统230耦合在一起。可理解的，总线系统230用于实现这些组件之间的连接通信。总线系统230除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统230。

处理器210可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器（DSP，Digital Signal Processor），或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

存储器240可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器240可选地包括在物理位置上远离处理器210的一个或多个存储设备。

存储器240包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器（ROM，Read Only Memory），易失性存储器可以是随机存取存储器（RAM，Random Access Memory）。本申请实施例描述的存储器240旨在包括任意适合类型的存储器。

在一些实施例中，存储器240能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统241，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块242，用于经由一个或多个（有线或无线）网络接口220到达其他计算设备，示例性的网络接口220包括：蓝牙、无线相容性认证（WiFi）、和通用串行总线（USB，Universal Serial Bus）等；

在一些实施例中，本申请实施例提供的信息推荐装置可以采用软件方式实现，图2示出了存储在存储器240中的信息推荐装置243，其可以是程序和插件等形式的软件，包括以下软件模块：接收模块2431、查询模块2432、获取模块2433、发送模块2434、存储模块2435、确定模块2436和删除模块2437，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。需要指出的是，在图2中为了方便表达，一次性示出了上述所有模块，但是不应视为在信息推荐装置243排除了可以只包括接收模块2431、查询模块2432、获取模块2433和发送模块2434的实施，将在下文中说明各个模块的功能。

下面继续对图1中示出的终端设备400的结构进行说明。参见图3，图3是本申请实施例提供的终端设备400的结构示意图。如图3所示，终端设备400包括：网络接口430、用户接口440、系统总线450、存储器460和处理器420。其中，用户接口440包括使得能够呈现媒体内容的一个或者多个输出装置441，包括一个或者多个扬声器和/或一个或多个视觉显示屏。用户接口440还包括一个或多个输入装置442，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。存储器460中包括：操作系统461、网络通信模块462、呈现模块463，用于经由一个或多个与用户接口440相关联的输出装置441（例如，显示屏、扬声器等）使得能够显示信息（例如，用于操作外围设备和显示内容和信息的用户接口）、输入处理模块464，用于对一个或多个来自一个或多个输入装置442之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动、信息推荐装置465。此外，存储在存储器460中的信息推荐装置465包括：发送模块4651、接收模块4652、显示模块4653和删除模块4654，这些模块是逻辑上的，因此可以根据所实现的功能进行任意的组合或进一步拆分，需要指出的是，在图3中为了方便表达，一次性示出了上述所有模块，但是不应视为在信息推荐装置465排除了可以只包括发送模块4651、接收模块4652和显示模块4653的实施，将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的信息推荐装置可以采用硬件方式实现，作为示例，本申请实施例提供的信息推荐装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的信息推荐方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路（ASIC，Application Specific IntegratedCircuit）、数字信号处理（DSP，Digital Signal Processing）、可编程逻辑器件（PLD，Programmable Logic Device）、复杂可编程逻辑器件（CPLD，Complex Programmable LogicDevice）、现场可编程门阵列（FPGA，Field-Programmable Gate Array）或其他电子元件。

下面将从客户端与服务器交互的角度对本申请实施例提供的信息推荐方法进行具体说明。示例的，参见图4，图4是本申请实施例提供的信息推荐方法的流程示意图，将结合图4示出的步骤进行说明。

在步骤101中，客户端向服务器发送针对目标对象的信息请求。

在一些实施例中，信息（包括推荐信息和运营信息）请求可以是客户端被刷新时发送的，且携带客户端的历史刷新数据以及已应用版本，其中，已应用版本是客户端中应用的运营策略的版本。

示例的，信息请求发送的时机可以是客户端启动时（当客户端启动时，需要获取相应的信息以展示给用户，因此，客户端的启动可以看作一种特殊的刷新），例如当用户首次打开终端设备上安装的客户端或者客户端从后台被重新切换回前台时，自动向服务器发送针对目标对象的信息请求；当然，信息请求发送的时机也可以是客户端接收到用户触发的刷新操作时，例如当客户端接收到用户触发的下拉刷新操作或者针对刷新按钮的点击操作时，向服务器发送针对目标对象的信息请求。

需要说明的是，在实际应用中，针对客户端发送的每个信息请求，服务器可以仅仅下发一次刷新的运营信息，或者，服务器也可以下发针对后续多次刷新分别配置的多个运营信息，从而不需要针对每次信息请求都返回运营信息，以节约服务器与客户端之间进行多次交互导致的资源浪费；并且，针对后一种情况（即服务器针对每个信息请求一次性下发针对后续多次刷新分别配置的多个运营信息的情况），只有在多次刷新分别配置的多个运营信息都被曝光后，客户端才会在后续的信息请求中携带运营信息、展示位置和版本等，以供服务器进行查询操作。

在步骤102中，服务器基于历史刷新数据以及已应用版本进行查询操作，得到待应用运营策略中针对从刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息。

在一些实施例中，历史刷新数据可以包括：客户端已完成的最新一次刷新使用的每个展示位置（例如可以以展示位置的序号进行表征，用于确定在客户端的信息流区域中插入的位置）、客户端已响应（即已经显示了相应的运营信息）的最新一次刷新对应的刷新次数，则服务器可以通过以下方式实现上述的步骤102：基于客户端已响应的最新一次刷新所使用的每个展示位置、以及最新一次刷新对应的刷新次数，对每个版本的运营策略进行查询操作（例如可以将客户端已响应的最新一次刷新所使用的每个展示位置、以及最新一次刷新对应的刷新次数组合为待查询的键，并基于组合得到的键，对独立于服务器部署的数据库、或者服务器自身的多刷多展示位置缓存中存储的每个版本的运营策略进行查询操作）；当在已应用版本的运营策略中查询到最新一次刷新的后续至少一次刷新时（即已应用版本的运营策略包括的多次刷新未完成），将已应用运营策略继续作为待应用运营策略，获取已应用版本的运营策略中针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息；当在已应用版本的运营策略中未查询到最新一次刷新的后续至少一次刷新时（即已应用版本的运营策略包括的多次刷新已完成），将已应用运营策略的后续版本作为待应用运营策略，并从待应用运营策略中获取针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息。

在另一些实施例中，每个版本的运营策略可以包括：针对客户端的多次刷新（每次刷新可以以对应的累计刷新次数进行表征）中的每次刷新所配置的至少一个展示位置（例如可以将刷新次数和展示位置组合为键）、针对配置的每个展示位置所配置的运营信息（例如可以采用运营信息的标识或者原始数据来记录所配置的运营信息）、以及运营策略的版本（例如可以将运营信息的标识和运营策略的版本组合为值），其中，每次刷新是基于对应的刷新次数表征的。

示例的，针对每个版本的运营策略，可以采用以下方式存储运营策略包括的内容：将刷新次数m-展示位置序号n为键（key），将运营信息的标识和运营策略的版本为值进行存储。例如，以运营策略A为例，假设运营策略A包括4次刷新，则可以采用表1的形式存储运营策略A包括的内容。其中，表1中示出的“1-2”表示刷新次数1-展示位置序号2，类似的，“2-2”表示刷新次数2-展示位置序号2；“ID1”表示“1-2”对应的运营信息的标识（即当客户端第一次被刷新时，将在客户端的信息流区域的第2个位置显示根据标识ID1获取的运营信息，例如运营信息1），类似的，“ID2”表示“2-2”对应的运营信息的标识（即当客户端第二次被刷新时，将在客户端的信息流区域的第2个位置显示根据标识ID2获取的运营信息，例如运营信息2），“V1”表示运营策略A的版本。

表1 运营策略A对应的键值表

键（key）	值（Value）
		1-2	ID1、V1
2-2	ID2、V1
		3-2	ID3、V1
4-2	ID4、V1

需要说明的是，表1是以每次刷新仅包括一个展示位置为例进行说明的，在实际应用中，当每次刷新包括多个展示位置时，还可以采用以下方式存储运营策略包括的内容：例如当每次刷新包括两个展示位置时，可以将刷新次数m-展示位置序号n-展示位置序号l作为键，举例来说，可以用“1-2-4”表示刷新次数1-展示位置序号2-展示位置序号4，同时假设“1-2-4”对应的值为“ID1、ID2、V1”，则当客户端第一次被刷新时，将在客户端的信息流区域的第2个位置显示根据标识ID1获取的运营信息（例如运营信息1）、以及在第4个位置显示根据标识ID2获取的运营信息（例如运营信息2）。

在一些实施例中，每个版本的运营策略还可以包括展示策略，其中，展示策略的类型包括：曝光策略，用于通过运营策略针对多次刷新分别配置的至少一个展示位置，显示一遍运营策略中针对配置的每个展示位置所配置的运营信息，并在多次刷新执行完毕后，停止在推荐信息流中插入运营策略所配置的任意一个展示位置；必出策略，用于通过运营策略针对多次刷新分别配置的至少一个展示位置，循环展示运营策略中针对配置的每个展示位置所配置的运营信息。

需要说明的是，客户端中的刷新包括展示位置和推荐信息流的刷新，二者是同步的，即在刷新推荐信息流的同时，刷新推荐信息流中插入的展示位置，例如当用户通过下拉操作来刷新推荐信息流时，展示位置也会同步刷新，并且在每次刷新时，展示位置在推荐信息流中插入的位置可以是相同的，例如在每次刷新时，展示位置始终在客户端的信息流区域的第2个位置插入；当然，也可以是不同的，例如在第一次刷新时，在客户端的信息流区域的第1个位置插入展示位置，在第二次刷新时，在客户端的信息流区域的第3个位置插入展示位置。

在另一些实施例中，每个版本的运营数据可以是以多刷多展示位置配置数据的形式存储在服务器的多刷多展示位置缓存中的，则服务器在进行查询操作之前，还可以执行以下处理：从独立于服务器部署的数据库中获取与目标对象适配的至少一个版本的运营策略；从与目标对象适配的至少一个版本的运营策略中，获取多刷多展示位置配置数据，其中，多刷多展示位置配置数据包括：针对客户端的多次刷新中的每次刷新所配置的至少一个展示位置、针对配置的每个展示位置所配置的一个处于有效期内的运营信息、以及运营策略的版本；将多刷多展示位置配置数据存储到多刷多展示位置缓存中，如此，当数据库无法被访问（例如发生故障、或者系统升级）时，可以将多刷多展示位置配置缓存作为查询操作的数据库，从而提高了稳定性。

需要说明的是，在实际应用中，每个版本的运营策略还可以包括有效期（例如对于同一个运营策略，可以是针对该运营策略所配置的所有运营信息标识对应的运营信息统一设定的），例如运营人员可以在运营策略配置平台中针对每个版本的运营策略设置对应的生效时间和失效时间，此外，还需要说明的是，在实际应用中，服务器也可以基于历史刷新数据以及已应用版本到数据库中进行查询，例如当服务器基于历史刷新数据以及已应用版本在多刷多展示位置缓存中查询结果为空时，可以基于历史刷新数据以及已应用版本到数据库中进行查询，本申请实施例对查询操作的数据源不作具体限定。

在一些实施例中，服务器可以通过以下方式实现上述的从独立于服务器部署的数据库中获取与目标对象适配的至少一个版本的运营策略：基于目标对象的标识从数据库中获取目标对象的特征（例如目标对象的客户端的业务版本、平台、操作系统版本、终端设备的类型等）；在多个候选的过滤条件组（又称配置组）中，确定与目标对象的特征匹配的至少一个过滤条件组，从数据库中获取至少一个过滤条件组关联的至少一个版本的运营策略。

示例的，运营人员可以预先配置多个过滤条件组，其中，每个过滤条件组可以包括以下过滤条件至少之一：业务版本条件，用于将客户端的业务版本与设定的业务版本进行比较，并根据比较结果进行过滤（例如假设运营人员在过滤条件组A中设定的业务版本为11.7.7，在过滤条件组B中设定的业务版本为11.7.6，假设客户端的业务版本为11.7.632，即客户端的业务版本小于过滤条件组A中设定的业务版本，但大于过滤条件组B中设定的业务版本，则确定目标对象与过滤条件组B匹配，与过滤条件组A不匹配，即将目标对象划分至过滤条件组B）；平台条件，用于将运行客户端的平台与设定的平台进行比较，并根据比较结果进行过滤（例如假设运营人员在过滤条件组A中设定的平台为IOS，在过滤条件组B中设定的平台为Android，假设客户端对应的平台为IOS，则确定目标对象与过滤条件组A匹配，与过滤条件组B不匹配）；操作系统版本条件，用于将运行客户端的操作系统的版本与设定的操作系统的版本进行比较，并根据比较结果进行过滤（例如假设运营人员在过滤条件组A中设定的操作系统的版本为10.3.1，在过滤条件组B中设定的操作系统的版本为10.3.3，假设客户端对应的操作系统的版本为10.3.2，即客户端对应的操作系统的版本大于过滤条件组A中设定的操作系统的版本，但小于过滤条件组B中设定的操作系统的版本，则确定目标对象与过滤条件组A匹配，与过滤条件组B不匹配）；终端设备类型条件，用于将运行客户端的终端设备的类型与设定的终端设备的类型进行比较，并根据比较结果进行过滤（例如假设运营人员在过滤条件组A中设定的终端设备的类型为手机，在过滤条件组B中设定的终端设备的类型为平板电脑，假设运行客户端的终端设备为手机，则确定目标对象与过滤条件组A匹配，与过滤条件组B不匹配）。

在步骤103中，服务器获取与目标对象的特征适配的推荐信息流。

在一些实施例中，服务器可以通过以下方式实现步骤103：基于目标对象的特征（例如基于目标对象的兴趣和行为得到的用户画像）对推荐信息库进行召回处理，得到多个推荐信息（即与目标对象的用户画像匹配的信息）；对召回的多个推荐信息进行排序，并获取排序结果中处于头部的N个推荐信息；其中，N为大于或者等于2的正整数；将所获取的N个推荐信息组成的推荐信息流，确定为与目标对象的特征适配的推荐信息流。

示例的，参见图5，图5是本申请实施例提供的获取推荐信息流的原理示意图，如图5所示，多通道召回层的功能主要是通过Spark计算引擎（例如YARD）从推荐信息库中召回与目标对象的特征匹配的信息，例如，可以通过日志采集系统所采集的用户历史行为数据确定出用户的用户画像，根据所确定出的用户画像召回匹配的相似视频、相似公众号、相似书籍等。例如，也可以获取实时的用户的行为，根据所获取的用户的实时行为召回与用户匹配的公众号文章、视频、书籍、热点队列、相似用户、实时相似内容等。例如，还可以拉取用户的社交队列服务，根据所拉取的社交队列服务召回匹配的社交队列、兴趣队列、以及动漫队列等。

重排层的功能主要是对召回的推荐信息进行排序。例如，可以对召回的推荐信息进行分类打散，按照信息的类型进行排序。举例来说，当召回的推荐信息中包括公众号文章、视频、书籍时，按照信息的类型对召回的推荐信息进行排序，即将公众号文章排在一起、视频排在一起、书籍排在一起，如此，一方面，可以方便用户进行浏览点击；另一方面，也使视觉效果的呈现更加美观。此外，也可以根据Bandit策略对召回的推荐信息进行排序。Bandit策略是指赋予信息一个贝塔分布，而不是单一的值。每次排序时通过采样随机获得一个排序值，通过这种随机性来加大推荐信息排序的变动性。同时，贝塔分布的均值会随着信息的表现而改变，这样就能对不同的信息进行区分，让表现好的信息有更大的概率获得高排序值，而不会像均匀分布那样每个信息的曝光几率保持不变。当然，也可以根据运营规则对召回的推荐信息进行排序。随后，可以从重排层输出的排序结果中获取位于头部的多个推荐信息，并将所获取的多个推荐信息组成推荐信息流，将推荐信息流发送给客户端。

在步骤104中，服务器向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息。

在一些实施例中，服务器在向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息之前，还可以执行以下处理：确定针对每个展示位置所配置的运营信息与推荐信息流的相似度（例如可以通过以下方式确定运营信息与推荐信息流的相似度：首先确定运营信息与推荐信息流中的每个推荐信息之间的相似度，接着将多个相似度的加和结果作为运营信息与推荐信息流的相似度）；过滤掉对应的相似度大于相似度阈值的运营信息，如此，能够保证运营信息与推荐信息流包括的推荐信息之间不重复，从而避免了将相似的信息重复推送给用户。

在另一些实施例中，服务器在向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息之后，还可以执行以下处理：删除多刷多展示位置缓存中过期（即超出有效期或者到达失效时间）的运营信息以及对应的运营信息标识；向客户端发送删除通知，用于使客户端删除客户端中存储的过期的运营信息以及对应的运营信息标识。

需要说明的是，在实际应用中，多次刷新的取值可以是预设值（例如10），即客户端中最多存储10次刷新分别配置的运营信息；当然，多次刷新的取值也可以是根据客户端的性能（例如客户端的可用缓存空间）动态决策的，例如当客户端的可用缓存空间较大时，多次刷新的取值也可以相对较大（例如15次），当客户端的可用缓存空间较小时，多次刷新的取值也可以相对较小（例如8次）。

在步骤105中，客户端显示推荐信息流，在推荐信息流中插入针对刷新所配置的至少一个展示位置，在插入的每个展示位置中显示对应配置的运营信息。

在一些实施例中，客户端在接收到服务器发送的推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息之后，可以在人机交互界面中显示推荐信息流，并在推荐信息流中插入针对刷新配置的至少一个展示位置，以及在插入的每个展示位置中显示对应配置的运营信息，如此，实现了运营信息在推荐信息流中的灵活插入，进而也丰富了推荐信息流包含的内容。

在另一些实施例中，参见图6A，图6A是本申请实施例提供的信息推荐方法的流程示意图，如图6A所示，当后续至少一次刷新是一次刷新时，在执行完图4示出的步骤105之后，还可以执行图6A示出的步骤106A至步骤108A，将结合图6A示出的步骤进行说明。

在步骤106A中，客户端向服务器发送携带待应用运营策略的版本的新信息请求。

在一些实施例中，服务器可以向客户端发送待应用运营策略的版本，从而在客户端被再次刷新时（例如客户端再次接收到用户触发的下拉刷新操作或者针对刷新按钮的点击操作），可以向服务器发送携带待应用运营策略的版本的新信息请求。

在步骤107A中，服务器向客户端发送新推荐信息流、新待应用运营策略针对再次刷新开始的后续至少一次刷新分别配置的至少一个新展示位置、以及针对配置的每个新展示位置所配置的新运营信息。

在一些实施例中，服务器在接收到客户端发送的新信息请求之后，从新信息请求中解析出待应用运营策略的版本，并基于待应用运营策略的版本进行查询操作，得到新待应用运营策略，其中，新待应用运营策略的版本是待应用运营策略的版本的后续更新版本，并且新待应用运营策略包括以下内容：针对再次刷新开始的后续至少一次刷新分别配置的至少一个新展示位置、以及针对配置的每个新展示位置所配置的新运营信息，接着服务器还可以根据新信息请求中携带的目标对象的特征获取新推荐信息流，随后服务器可以将新推荐信息流、新待应用运营策略针对再次刷新开始的后续至少一次刷新分别配置的至少一个新展示位置、以及针对配置的每个新展示位置所配置的新运营信息返回给客户端。

在步骤108A中，客户端显示新推荐信息流，在新推荐信息流中插入针对再次刷新所配置的至少一个新展示位置，在插入的每个新展示位置中显示对应配置的新运营信息。

在一些实施例中，客户端在接收到服务器返回的新推荐信息流、针对再次刷新开始的后续至少一次刷新分别配置的至少一个新展示位置、以及针对配置的每个新展示位置所配置的新运营信息之后，可以在人机交互界面中显示新推荐信息流，并在新推荐信息流中插入针对再次刷新所配置的至少一个新展示位置、以及在插入的每个新展示位置中显示对应配置的新运营信息。

示例的，针对后续至少一次刷新是一次刷新的情况，客户端与服务器之间的交互过程如下：客户端向服务器发送信息请求1，服务器向客户端返回推荐信息流1和运营信息1，接着客户端向服务器发送信息请求2，服务器向客户端返回推荐信息流2和运营信息2，以此类推。也就是说，针对客户端发送的每个信息请求，服务器仅向客户端返回一次刷新配置的运营信息。

在另一些实施例中，参见图6B，图6B是本申请实施例提供的信息推荐方法的流程示意图，如图6B所示，当后续至少一次刷新是多次刷新时，在执行完图4示出的步骤105之后，还可以执行图6B示出的步骤106B至步骤108B，将结合图6B示出的步骤进行说明。

在步骤106B中，客户端向服务器发送推荐请求。

在一些实施例中，当客户端被再次刷新时，可以向服务器发送推荐请求，其中，当再次刷新发生时多次刷新未完成，例如假设多次刷新为4次刷新，当客户端被再次刷新时（例如客户端被第2次刷新，此时4次刷新未完成），则可以向服务器发送推荐请求。

在步骤107B中，服务器向客户端发送目标对象对应的新推荐信息流。

在一些实施例中，服务器在接收到客户端发送的推荐请求之后，可以获取推荐请求中携带的目标对象的特征，并基于目标对象的特征从推荐信息库中获取与目标对象对应的新推荐信息流，随后服务器可以将获取的新推荐信息流发送给客户端。

在步骤108B中，客户端显示新推荐信息流，在新推荐信息流中，插入待应用运营策略针对再次刷新所配置的至少一个展示位置，在插入的每个展示位置中显示对应配置的运营信息。

在一些实施例中，客户端在接收到服务器返回的新推荐信息流之后，可以在人机交互界面中显示新推荐信息流，并在新推荐信息流中，插入待应用运营策略中针对再次刷新所配置的至少一个展示位置，以及在插入的每个展示位置中显示对应配置的运营信息。

示例的，针对后续至少一次刷新为多次刷新的情况，客户端与服务器之间的交互过程如下：客户端向服务器发送信息请求1，服务器向客户端返回推荐信息流1和待应用运营策略（例如运营策略A），其中，运营策略A包括N次（例如4次）刷新分别配置的至少一个展示位置、以及针对配置的每个展示位置所配置的运营信息，以供客户端显示推荐信息流1，并在推荐信息流1中插入运营策略A中针对第1次刷新配置的至少一个展示位置、以及针对配置的每个展示位置所配置的运营信息（例如在推荐信息流1中的第2个位置插入展示位置，并在展示位置中显示运营信息1）；接着响应于客户端被再次刷新（即客户端被第2次刷新，此时4次刷新未完成），向服务器发送推荐请求1，服务器在接收到客户端发送的推荐请求1后，向客户端返回与目标对象对应的推荐信息流2，以供客户端显示推荐信息流2，并在推荐信息流2中插入运营策略A中针对第2次刷新配置的至少一个展示位置、以及针对配置的每个展示位置所配置的运营信息（例如在推荐信息流2中的第1个位置插入展示位置，并在展示位置中显示运营信息2）；响应于客户端被第3次刷新（此时4次刷新仍没有完成），向服务器发送推荐请求2，服务器在接收到客户端发送的推荐请求2之后，向客户端返回推荐信息流3，以供客户端显示推荐信息流3，并在推荐信息流3中插入运营策略A中针对第3次刷新配置的至少一个展示位置、以及针对配置的每个展示位置所配置的运营信息（例如在推荐信息流3中的第1个位置和第3个位置分别插入展示位置，并在展示位置中显示运营信息3和运营信息4）；响应于客户端被第4次刷新（此时第4次刷新配置的运营信息还没有曝光），向服务器发送推荐请求3，服务器在接收到客户端发送的推荐请求3之后，向客户端返回推荐信息流4，以供客户端显示推荐信息流4，并在推荐信息流4中插入运营策略A中针对第4次刷新配置的至少一个展示位置、以及针对配置的每个展示位置所配置的运营信息（例如在推荐信息流4中的第2个位置插入展示位置，并在展示位置中显示运营信息5）；响应于客户端被第5次刷新（此时运营策略A中包括的4次刷新分别配置的运营信息已经全部曝光），向服务器发送信息请求2，以使服务器返回推荐信息流5和新待应用运营策略（例如运营策略B，其中，运营策略B的版本是运营策略A的后续的更新版本）。

下面继续从客户端的角度对本申请实施例提供的信息推荐方法进行说明。

在一些实施例中，响应于客户端被刷新，显示推荐信息流，以及在推荐信息流中插入至少一个展示位置，并在插入的每个展示位置中显示对应配置的运营信息；其中，针对多次刷新分别插入（即配置）的至少一个展示位置，用于循环显示对应配置的运营信息（即对应于上述的必出策略），或者，在展示一遍对应配置的运营信息后隐藏（即对应于上述的曝光策略）。

本申请实施例提供的信息推荐方法，针对客户端的每次刷新，独立配置在推荐信息流中插入的展示位置、以及每个展示位置所配置的运营信息，如此，能够实现不同运营信息在推荐信息流中的灵活插入。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用。

推荐信息流是基于用户的兴趣（例如美食、游戏、电影、运动等）和行为（例如点赞、收藏、评论、转发等）进行离线或者用户请求时在线计算得出多个推荐信息提供给用户进行浏览。但是，对于一些特殊场景，例如想针对用户在推荐信息流中插入广告、热点内容、运营活动等运营信息来达到丰富推荐信息流的效果，则需要根据一些运营策略来做相应运营信息的插入处理。

鉴于此，本申请实施例提供一种信息推荐方法，基于相关技术提供的前后端技术，提供了一个易用、扩展性好的推荐信息流结合运营信息的解决方案来达到在推荐信息流中插入相应的运营信息的目的，从而实现提高用户的观看量。

本申请实施例提供的信息推荐方法能够满足多种运营策略、以及易用的推荐信息流结合运营信息的解决方案，在原有用于定制化的推荐信息流基础上，支持多种运营信息的插入和展示策略的能力，在保证预期推荐信息流正常返回的情况下，插入不同的运营策略，并保证推荐信息流包括的推荐信息与运营信息是不重复的。在保证推荐内容个性化的前提下，丰富了推荐信息流，支持热点内容和广告活动的插入，提高了推荐内容的丰富度、从而增加用户对推荐信息流的观看量、观看时长等。

本申请实施例提供的信息推荐方法可以应用于各种需要推荐流的业务场景，推荐信息的内容包括但不限于视频、图文等。

示例的，参见图7，图7是本申请实施例提供的信息推荐方法的应用场景示意图，如图7所示，用户在进行第一次刷新操作时，在客户端的人机交互界面显示页面701，在页面701中显示有正常返回的推荐信息702、以及根据运营策略返回的运营信息703，当用户进行第二次刷新操作时，在客户端的人机交互界面显示页面704，在页面704中显示有正常返回的推荐信息705、以及根据运营策略返回的运营信息706，其中，运营信息703在页面701中所处的位置与运营信息706在页面704中所处的位置相同，即针对不同的刷新次数，可以在相同的展示位置显示运营信息。

示例的，参见图8，图8是本申请实施例提供的信息推荐系统的架构示意图，如图8所示，本申请实施例提供的信息推荐系统主要包括以下五个模块：客户端、特征过滤平台、业务后台（与运营方对应，例如运营方可以通过业务后台在推荐信息流中插入运营信息）、运营策略配置平台和推荐平台，其中，客户端主要用于记录用户之前刷的运营位数据状态（例如上一次刷新时曝光的运营信息、以及运营策略的版本等），每次请求时将之前刷的运营位数据状态提供给业务后台，以进行相应新的运营信息的插入；特征过滤平台主要用于提供区分业务版本、操作系统、平台和人群的能力；业务后台用于实现推荐信息的过滤和运营信息的插入逻辑；运营策略配置平台用于为运营人员提供运营信息的配置能力；推荐平台用于根据用户的特征提供个性化的推荐信息。下面将针对上述五个模块进行具体说明。

本申请实施例提供的信息推荐方法支持多个运营信息的插入，并支持针对插入的多个运营信息配置对应的展示策略，下面选取两种较为典型的展示策略进行说明。

示例的，参见图9，图9是本申请实施例提供的曝光策略的示意图，如图9所示，针对单个用户（例如用户A），假设运营人员在运营策略配置平台中针对m刷n位（例如4刷2位）配置了A、B、C、D四个运营信息，则用户在进行第一次刷新操作时，在人机交互界面的第2个位置显示运营信息A，在进行第二次刷新操作时，在人机交互界面的第2个位置显示运营信息B，以此类推，当该位置所有的运营信息顺序显示（即曝光）之后，该位置不再插入运营信息，正常展示推荐信息流包括的推荐信息。

示例的，参见图10，图10是本申请实施例提供的必出策略的示意图，如图10所示，针对单个用户（例如用户B），假设运营人员在运营策略配置平台中针对m刷n位（例如4刷3位）配置了A、B、C、D四个运营信息，则用户在进行第一次刷新操作时，在人机交互界面的第3个位置显示运营信息A，在进行第二次刷新操作时，在人机交互界面的第3个位置显示运营信息B，以此类推，当该位置所有的运营信息顺序曝光之后，重头开始循环曝光，保持该位置的运营信息插入（即当用户在进行第五次刷新操作时，在人机交互界面的第3个位置重新显示运营信息A，当在进行第六次刷新操作时，在人机交互界面的第3个位置重新显示运营信息B，以此类推）。

需要说明的是，上述示例是以针对不同刷在相同的位置显示运营信息为例进行说明的，在实际应用中，针对不同刷还可以在不同的位置显示运营信息，例如用户在进行第一次刷新操作时，在人机交互界面的第2个位置显示运营信息A，在进行第二次刷新操作时，在人机交互界面的第3个位置显示运营信息B，即在不同刷中在不同的位置显示运营信息。

下面对图8中示出的客户端进行具体说明。

示例的，参见图11，图11是本申请实施例提供的客户端的存储示意图，如图11所示，每个用户在各自的终端（例如手机）上存储以m刷_n位为key的上一刷的运营信息，同时记录该配置的版本（即当前应用的运营策略的版本，不同版本的运营策略对应的运营信息是不同的）。比如运营人员配置了运营策略A包括的4刷2位的运营信息分别为A、B、C、D，即用户在第一次刷新时，在推荐信息流的第二位插入运营信息A，同时客户端在手机本地记下key：“1_2”，值为本次曝光的运营信息A，以及相应的版本。当客户端（已经展示完成了业务后台下发的多刷的运营信息）发送下次用户请求的时候，只需在请求中携带上一次在该位置刷到的运营信息A（例如运营信息A的ID）和运营策略的版本，则业务后台即可知道应该循环往下取运营信息B曝光在该位置，以此类推。引入版本的概念是为了避免同一位置前后两次更新出现的顺序出错问题（因为不同版本的运营策略配置的运营信息的顺序可能是不同的）。比如运营人员首次配置了运营信息A、B、C、D，第二次配置了运营信息C、B、E、F，当客户端请求业务后台的时候携带上一次该位置的运营信息B时，如果不携带运营策略的版本，那么按顺序返回的就是当前更新的下一个运营信息E，但是此时当前位置的配置的运营信息是有变更的，所以应该首先从首次配置的顺序，即从运营信息C开始循环，也就是说，在第一次配置的多个运营信息曝光结束后，才执行第二次配置的运营信息。因此，通过引入版本可以提高插入运营信息的准确性。

此外，如图12所示，按上述方法记录数据（即以m刷_n位的形式存储运营信息）客户端无法知道什么时候需要删除在客户端中缓存的运营信息，可能导致客户端本地存储的运营信息无限增大的情况，所以为了限制存储增长，针对每个位置限制最多配置到10刷的运营信息；除此之外，业务后台需要告诉客户端什么时候清除对应的数据（即当某个运营信息到达失效时间后业务后台可以告诉客户端清除本地缓存中对应的运营信息），否则客户端会永久保存相应的运营信息，客户端传m刷n位的运营信息到业务后台的时候，当业务后台在本地缓存无法查到某个配置的运营信息（失效的运营信息会从缓存中清除）的时候，需要告诉客户端将对应key的运营信息删除，例如当客户端传2刷_2位的运营信息（即运营信息B）到业务后台的时候，由于3刷_2位的运营信息（即运营信息C）处于失效状态，即业务后台无法在本地缓存中查到运营信息C，则可以给客户端发送删除通知，以通知客户端删除本地缓存的3刷_2位对应的运营信息。

下面对图8中示出的特征过滤平台进行具体说明。

示例的，参见图13，图13是本申请实施例提供的基于特征过滤平台进行用户请求分组的示意图，如图13所示，每个用户请求对应一个业务串，其中，每个业务串的内容包括但不限于平台、版本、操作系统和用户ID等信息，特征过滤平台根据业务串和运营人员在特征过滤平台上配置的过滤条件（例如运营人员可以在特征过滤平台配置多个配置组，每个配置组包括至少一个用于过滤的条件），将不同的业务串匹配到对应的配置组（对应于上述的条件过滤组），以实现对用户请求进行分组，其中，每个配置组关联有一个运营策略ID（例如图13中示出的运营策略ID1是与配置组A关联的，运营策略ID2是与配置组B关联的，运营策略Idn是与配置组N关联的），并且，如图8所示，在基于特征过滤平台获取到与用户请求对应的运营策略ID之后，可以将获取到的运营策略ID发送给业务后台执行后续的处理。

在一些实施例中，业务串包括的不同信息之间可以用分号“&”进行分割，在业务串被传入特征过滤平台时会进行分割处理，例如对业务串“PL=IOS&DE=PHONE&OS=14.6&PPVN=11.7.7.5131”进行分割处理之后，可以得到四个参数：PL=IOS、DE=PHONE、OS=14.6、PPVN=11.7.7.5131，分别对应于平台为IOS、设备类型为手机、操作系统版本为14.6和客户端对应的业务版本为11.7.7.5131。

在另一些实施例中，运营人员在特征过滤平台配置的多个过滤条件之间可以为“与”的关系，例如假设运营人员在特征过滤平台配置了一个配置组A的条件为：平台为IOS、业务版本大于11.7.7；另一个配置组B的条件为：平台为Android、业务版本大于11.7.7，以业务串为上述示例的业务串为例，由于上述示例的业务串包括的平台为IOS，业务版本为11.7.7.5131，因此，上述示例的业务串满足配置组A的条件（即同时满足平台条件和业务版本条件），但不满足配置组B的条件（即仅满足业务版本条件，但不满足平台条件），所以针对上述示例的业务串，特征过滤平台会返回配置组A关联的运营策略ID，并发送给业务后台使用。

示例的，参见图14，图14是本申请实施例提供的基于特征过滤平台对业务串进行匹配的示意图，如图14所示，运营人员在特征过滤平台中配置了多个配置组，例如包括配置组A、配置组B、配置组C、…、配置组N，在将业务串传入特征过滤平台之后，将业务串包括的信息与各个配置组的条件进行匹配，例如假设该业务串同时满足配置组A和配置组C的条件，则特征过滤平台可以同时将配置组A关联的运营配置ID（例如运营配置ID1）和配置组C关联的运营配置ID（例如运营配置ID3）发送给业务后台。

需要说明的是，特征过滤平台的其他筛选条件，例如用户兴趣、用户地区等，可以作为基于用户ID的平台离线数据给用户打上对应的标签，从而基于用户对应的标签进行过滤。

下面对图8中示出的运营策略配置平台进行具体说明。

运营策略配置平台为运营人员提供了一个支持多种运营信息的插入和展示策略的配置后台，运营人员可以在运营策略配置平台上配置相应的运营信息、以及对应的运营策略，运营策略可以用于上述的特征过滤平台区分不同的人群（即特征过滤平台中的不同配置组关联有不同的运营策略ID）。此外，运营策略配置平台还支持基于后台接口的内容自动拉取和不同运营策略配置的功能，能够覆盖运营所需的大部分场景。例如，运营人员可以在运营策略配置平台中配置如表2所示的运营策略表。

表2 运营策略表

Key	类型	说明
			ids	int	运营策略所使用的多个运营信息分别对应的标识，用于区分不同运营信息所使用的素材
rowkey	string	多个运营信息的key组成rowkey，rowkey包括的多个key之间用“；”分割
			version	int	版本信息
create_time	datetime	创建时间
			strategy_id	int	运营策略id，用于特征过滤平台区分不同的人群
operation_strategy	int	展示策略，例如上述的必出策略和曝光策略，用枚举表示
			valid_time	datetime	生效时间
invalid_time	datetime	失效时间

下面对图8中示出的业务后台进行具体说明。

在一些实施例中，因为运营人员在运营策略配置平台中配置的运营策略是通用的，所以为了减少数据库压力和网络开销，业务后台定期从运营策略配置平台配置的运营位内容存储（即数据库）中拉取运营人员配置的运营策略存到本地缓存，然后根据每次用户的请求做筛选处理即可。

示例的，参见图15，图15是本申请实施例提供的业务后台的本地缓存示意图，如图15所示，基于上述运营配置策略平台的数据库（即图8中示出的运营位内容存储）中存储的运营信息，将当前时间在生效时间和失效时间之间的运营信息缓存到业务后台本地，本地采用双映射的结构，记录每个客户端对应的m刷和n位的运营信息和运营策略的版本信息，根据客户端请求中当前m刷n位用户上一次刷到的运营信息以及对应的运营策略的版本返回相应的下一个运营信息（例如在业务后台存储有版本1的运营策略和版本2的运营策略，对于版本1的运营策略，包括A、B、C、D四个运营信息，且对应的展示策略为曝光策略；而对于版本2的运营策略，包括C、D、E、F四个运营信息，且对应的展示策略为必出策略，当业务后台接收到客户端发送的2刷_2位的运营信息（即运营信息B）以及运营策略的版本（即版本1）时，获取版本1的运营策略中3刷_2位的运营信息（即运营信息C），并将运营信息C返回给客户端）。基于本地缓存的设计，业务后台无需每次都去请求数据库，减少了网络开销，提高了响应速度。

示例的，参见图16，图16是本申请实施例提供的在推荐信息流中插入运营内容的示意图，如图16所示，业务后台在推荐信息流中插入运营内容的逻辑为向后挤的方式而非替换的方式，例如假设推荐信息流每一刷固定为5个推荐内容，举例来说，假设当前刷推荐平台下发的推荐内容为A、B、C、D、E，而运营人员在运营策略配置平台中配置了该刷第1位为运营内容X，第3位为运营内容Y，则按往后挤的方式进行插入，首先在第1位插入运营内容X，则推荐信息流包括的5个内容变成X、A、B、C、D，再在第3位插入运营内容Y后，推荐信息流包括的5个内容变成X、A、Y、B、C。

下面对图8中示出的推荐平台进行具体说明。

推荐平台可以基于用户的唯一ID进行个性化推荐，并返回对应的推荐信息流提供给业务后台进行运营信息的插入处理（即业务后台根据运营人员在运营策略配置平台中配置的运营策略，在推荐平台返回的推荐信息流的相应位置插入展示位置，并在展示位置中显示所配置的运营信息），并且，业务后台在根据运营策略插入运营信息之前，会将运营信息与推荐平台返回的推荐信息流进行对比，从而保证插入的运营信息与推荐平台返回的推荐信息流包括的推荐信息不重复。

本申请实施例提供的信息推荐系统具有较好的扩展性和稳定性，其中，系统的扩展性是基于运营策略配置平台的策略配置，业务后台可以根据运营人员在运营策略配置平台中配置的运营策略进行兼容处理，完成运营信息不同的插入逻辑；此外，特征过滤平台支持多维度的过滤筛选，例如用户标签、版本、平台等信息，从而满足不同的运营应用场景。另一方面，因为系统基于运营策略配置平台的数据库（即图8中示出的运营位内容存储）做了本地缓存，所以只要服务启动，业务后台首先保证加载到数据，如果后面遇到配置变更或者数据库不可用等问题导致没有数据，本地缓存的数据不会被覆盖，将继续保证线上有数据返回，以此做降级返回保证了系统的稳定性。

本申请实施例提供的信息推荐方法，基于现有的特征过滤系统和推荐平台实现了一个扩展性强，稳定性高的基于用户推荐信息流结合运营信息的解决方案。本申请实施例支持不同运营策略的配置，可以实现在原有单一的推荐信息流中插入广告、活动数据、热点内容等运营信息，丰富推荐信息流的内容，提高推荐信息流为APP带来的各种效益。同时，本申请实施例还支持了基于不同用户人群的运营策略方案，可基于此做一些实验设计和数据分析。

下面继续说明本申请实施例提供的信息推荐装置243的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器240的信息推荐装置243中的软件模块可以包括：接收模块2431、查询模块2432、获取模块2433和发送模块2434。

接收模块2431，用于接收客户端发送的针对目标对象的信息请求；其中，信息请求是客户端被刷新时发送的，且携带客户端的历史刷新数据以及已应用版本，已应用版本是客户端中应用的运营策略的版本；查询模块2432，用于基于历史刷新数据以及已应用版本进行查询操作，得到待应用运营策略中针对从刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息；获取模块2433，用于获取与目标对象的特征适配的推荐信息流；发送模块2434，用于向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息，以供客户端进行刷新显示。

在一些实施例中，历史刷新数据包括：客户端已完成的最新一次刷新使用的每个展示位置、客户端已响应的最新一次刷新对应的刷新次数；查询模块2432，还用于基于客户端已响应的最新一次刷新所使用的每个展示位置、最新一次刷新对应的刷新次数，对每个版本的运营策略进行查询操作；其中，每个版本的运营策略包括：针对客户端的多次刷新中的每次刷新所配置的至少一个展示位置、针对配置的每个展示位置所配置的运营信息、运营策略的版本，每次刷新是基于对应的刷新次数表征的；当在已应用版本的运营策略中查询到最新一次刷新的后续至少一次刷新时，将已应用运营策略继续作为待应用运营策略，获取已应用版本的运营策略中针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息；当在已应用版本的运营策略中未查询到最新一次刷新的后续至少一次刷新时，将已应用运营策略的后续版本作为待应用运营策略，并从待应用运营策略中获取针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息。

在一些实施例中，每个版本的运营策略是以多刷多展示位置配置数据的形式存储在服务器的多刷多展示位置缓存中的，获取模块2433，还用于在进行查询操作之前，从独立于服务器部署的数据库中获取与目标对象适配的至少一个版本的运营策略；从与目标对象适配的至少一个版本的运营策略中，获取多刷多展示位置配置数据，多刷多展示位置配置数据包括：针对客户端的多次刷新中的每次刷新所配置的至少一个展示位置、针对配置的每个展示位置所配置的的处于有效期的运营信息、运营策略的版本；其中，每个版本的运营策略还包括有效期；信息推荐装置243还包括存储模块2435，用于将多刷多展示位置配置数据存储到多刷多展示位置缓存中。

在一些实施例中，获取模块2433，还用于基于目标对象的标识从数据库中获取目标对象的特征；信息推荐装置243还包括确定模块2436，用于在多个候选的过滤条件组中，确定与目标对象的特征匹配的至少一个过滤条件组；获取模块2433，还用于从数据库中获取至少一个过滤条件组关联的至少一个版本的运营策略。

在一些实施例中，过滤条件组包括以下过滤条件至少之一：业务版本条件，用于将客户端的业务版本与设定的业务版本进行比较，并根据比较结果进行过滤；平台条件，用于将运行客户端的平台与设定的平台进行比较，并根据比较结果进行过滤；操作系统版本条件，用于将运行客户端的操作系统的版本与设定的操作系统的版本进行比较，并根据比较结果进行过滤；终端设备类型条件，用于将运行客户端的终端设备的类型与设定的终端设备的类型进行比较，并根据比较结果进行过滤。

在一些实施例中，信息推荐装置243还包括删除模块2437，用于在向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息之后，删除多刷多展示位置缓存中过期的运营信息以及对应的运营信息标识；发送模块2434，还用于向客户端发送删除通知，用于使客户端删除客户端中存储的过期的运营信息以及对应的运营信息标识。

在一些实施例中，每个版本的运营策略以多刷多展示位置配置数据的形式存储在服务器的多刷多展示位置缓存中，并且，每个版本的运营策略存储在独立于服务器部署的数据库中；确定模块2436，还用于当数据库无法被访问时，将多刷多展示位置缓存作为查询操作的数据源。

在一些实施例中，每个版本的运营策略还包括展示策略，展示策略的类型包括：曝光策略，用于通过运营策略针对多次刷新分别配置的至少一个展示位置，显示一遍运营策略中针对配置的每个展示位置所配置的运营信息，并在多次刷新执行完毕后，停止在推荐信息流中插入运营策略所配置的任意一个展示位置；必出策略，用于通过运营策略针对多次刷新分别配置的至少一个展示位置，循环显示运营策略中针对配置的每个展示位置所配置的运营信息。

在一些实施例中，确定模块2436，还用于在向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息之前，确定针对每个展示位置所配置的运营信息与推荐信息流的相似度；删除模块2437，还用于过滤掉对应的相似度大于相似度阈值的运营信息。

在一些实施例中，当后续至少一次刷新是一次刷新，且当向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息时，发送模块2434，还用于向客户端发送待应用运营策略的版本，以供客户端被再次刷新时，发送携带待应用运营策略的版本的新信息请求。

在一些实施例中，当后续至少一次刷新是多次刷新，且在向客户端发送推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息之后，接收模块2431，还用于接收客户端发送的推荐请求；其中，推荐请求是客户端被再次刷新时发送的，且后续的多次刷新未完成；获取模块2433，还用于获取与目标对象对应的新推荐信息流；发送模块2434，还用于向客户端发送新推荐信息流，以使客户端显示新推荐信息流，并在新推荐信息流中，插入待应用运营策略针对再次刷新所配置的至少一个展示位置，在插入的每个展示位置中显示对应配置的运营信息。

在一些实施例中，获取模块2433，还用于基于目标对象的特征对推荐信息库进行召回处理，得到多个推荐信息；对多个推荐信息进行排序，并获取排序结果中处于头部的N个推荐信息；其中，N为大于或者等于2的正整数；将N个推荐信息组成的推荐信息流，确定为与目标对象的特征适配的推荐信息流。

下面继续说明本申请实施例提供的信息推荐装置465的实施为软件模块的示例性结构，在一些实施例中，如图3所示，存储在存储器460中的信息推荐装置465中的软件模块可以包括：发送模块4651、接收模块4652和显示模块4653。

发送模块4651，用于响应于针对客户端的刷新，向服务器发送针对目标对象的信息请求；其中，信息请求中携带用于供服务器进行查询操作的客户端的历史刷新数据以及已应用版本，已应用版本是客户端中应用的运营策略的版本；接收模块4652，用于接收服务器在进行查询操作后返回的推荐信息流、针对从刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对配置的每个展示位置所配置的运营信息；显示模块4653，用于显示推荐信息流，在推荐信息流中插入针对刷新所配置的至少一个展示位置，在插入的每个展示位置中显示对应配置的运营信息。

在一些实施例中，当后续至少一次刷新是一次刷新，且在插入的每个展示位置中显示对应配置的运营信息之后，发送模块4651，还用于响应于客户端被再次刷新，发送携带待应用运营策略的版本的新信息请求；接收模块4652，还用于接收服务器返回的新推荐信息流、新待应用运营策略针对从再次刷新开始的后续至少一次刷新分别配置的至少一个新展示位置、以及针对配置的每个新展示位置所配置的新运营信息；其中，新待应用运营策略的版本是待应用运营策略的版本的后续更新版本；显示模块4653，还用于显示新推荐信息流，在新推荐信息流中插入针对再次刷新所配置的至少一个新展示位置，在插入的每个新展示位置中显示对应配置的新运营信息。

在一些实施例中，当后续至少一次刷新是多次刷新，且在插入的每个展示位置中显示对应配置的运营信息之后，发送模块4651，还用于响应于针对客户端的再次刷新，向服务器发送推荐请求；其中，当再次刷新发生时多次刷新未完成；接收模块4652，还用于接收服务器发送的目标对象对应的新推荐信息流；显示模块4653，还用于显示新推荐信息流，并在新推荐信息流中，插入待应用运营策略针对再次刷新所配置的至少一个展示位置，在插入的每个展示位置中显示对应配置的运营信息。

在一些实施例中，每个版本的运营策略还包括展示策略；当待应用运营策略包括的展示策略是曝光策略、且待应用运营策略中配置的多次刷新执行完毕时，显示模块4653，还用于停止显示待应用运营策略针对多次刷新分别配置的至少一个展示位置；当待应用运营策略包括的展示策略是必出策略、且待应用运营策略中配置的多次刷新执行完毕时，显示模块4653，还用于通过待应用运营策略针对多次刷新分别配置的至少一个展示位置，循环显示运营策略中针对配置的每个展示位置所配置的运营信息。

在一些实施例中，接收模块4652，还用于接收服务器的删除通知；其中，删除通知包括过期的运营信息；信息推荐装置465还包括删除模块4654，用于删除客户端中缓存过期的运营信息。

需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本申请实施例提供的信息推荐装置中未尽的技术细节，可以根据图4、图6A、或图6B任一附图的说明而理解。

本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例上述的信息推荐方法。

本申请实施例提供一种存储有可执行指令的计算机可读存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的信息推荐方法，例如，如图4、图6A、或图6B示出的信息推荐方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EPROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言（包括编译或解释语言，或者声明性或过程性语言）来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言（HTML，Hyper TextMarkup Language）文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件（例如，存储一个或多个模块、子程序或代码部分的文件）中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

综上所述，本申请实施例针对客户端的每次刷新，独立配置在推荐信息流中插入的展示位置、以及每个展示位置所配置的运营信息，如此，能够实现不同运营信息在推荐信息流中的灵活插入。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (20)

1.一种信息推荐方法，其特征在于，所述方法包括：

接收客户端发送的针对目标对象的信息请求；其中，所述信息请求是所述客户端被刷新时发送的，且携带所述客户端的历史刷新数据以及已应用版本，所述已应用版本是所述客户端中应用的运营策略的版本；

基于所述历史刷新数据以及所述已应用版本进行查询操作，得到待应用运营策略中针对从所述刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息；

获取与所述目标对象的特征适配的推荐信息流；

向所述客户端发送所述推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息，以供所述客户端进行刷新显示。

2.根据权利要求1所述的方法，其特征在于，

所述历史刷新数据包括：所述客户端已完成的最新一次刷新使用的每个展示位置、所述客户端已响应的最新一次刷新对应的刷新次数；

所述基于所述历史刷新数据以及所述已应用版本进行查询操作，得到待应用运营策略中针对从所述刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个展示位置所配置的运营信息，包括：

基于所述客户端已响应的最新一次刷新所使用的每个展示位置、所述最新一次刷新对应的刷新次数，对每个版本的所述运营策略进行查询操作；

其中，每个版本的所述运营策略包括：针对所述客户端的多次刷新中的每次刷新所配置的至少一个展示位置、针对配置的每个所述展示位置所配置的运营信息、所述运营策略的版本，所述每次刷新是基于对应的刷新次数表征的；

当在所述已应用版本的运营策略中查询到所述最新一次刷新的后续至少一次刷新时，将所述已应用运营策略继续作为待应用运营策略，获取所述已应用版本的运营策略中针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息；

当在所述已应用版本的运营策略中未查询到所述最新一次刷新的后续至少一次刷新时，将所述已应用运营策略的后续版本作为待应用运营策略，并从所述待应用运营策略中获取针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息。

3.根据权利要求1所述的方法，其特征在于，每个版本的所述运营策略是以多刷多展示位置配置数据的形式存储在服务器的多刷多展示位置缓存中的，在进行所述查询操作之前，所述方法还包括：

从独立于所述服务器部署的数据库中获取与所述目标对象适配的至少一个版本的运营策略；

从与所述目标对象适配的至少一个版本的运营策略中，获取多刷多展示位置配置数据，所述多刷多展示位置配置数据包括：针对所述客户端的多次刷新中的每次刷新所配置的至少一个展示位置、针对配置的每个所述展示位置所配置的的处于有效期的运营信息、所述运营策略的版本；其中，每个版本的所述运营策略还包括有效期；

将所述多刷多展示位置配置数据存储到所述多刷多展示位置缓存中。

4.根据权利要求3所述的方法，其特征在于，

所述从独立于所述服务器部署的数据库中获取与所述目标对象适配的至少一个版本的运营策略，包括：

基于所述目标对象的标识从所述数据库中获取所述目标对象的特征；

在多个候选的过滤条件组中，确定与所述目标对象的特征匹配的至少一个过滤条件组，从所述数据库中获取所述至少一个过滤条件组关联的至少一个版本的运营策略。

5.根据权利要求4所述的方法，其特征在于，

所述过滤条件组包括以下过滤条件至少之一：

业务版本条件，用于将所述客户端的业务版本与设定的业务版本进行比较，并根据比较结果进行过滤；

平台条件，用于将运行所述客户端的平台与设定的平台进行比较，并根据比较结果进行过滤；

操作系统版本条件，用于将运行所述客户端的操作系统的版本与设定的操作系统的版本进行比较，并根据比较结果进行过滤；

终端设备类型条件，用于将运行所述客户端的终端设备的类型与设定的终端设备的类型进行比较，并根据比较结果进行过滤。

6.根据权利要求3所述的方法，其特征在于，在向所述客户端发送所述推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息之后，所述方法还包括：

删除所述多刷多展示位置缓存中过期的运营信息以及对应的运营信息标识；

向所述客户端发送删除通知，用于使所述客户端删除所述客户端中存储的所述过期的运营信息以及对应的运营信息标识。

7.根据权利要求1所述的方法，其特征在于，

每个版本的所述运营策略以多刷多展示位置配置数据的形式存储在服务器的多刷多展示位置缓存中，并且，每个版本的所述运营策略存储在独立于所述服务器部署的数据库中；

所述方法还包括：

当所述数据库无法被访问时，将所述多刷多展示位置缓存作为所述查询操作的数据源。

8.根据权利要求1所述的方法，其特征在于，

每个版本的所述运营策略还包括展示策略，所述展示策略的类型包括：

曝光策略，用于通过所述运营策略针对多次刷新分别配置的至少一个展示位置，显示一遍所述运营策略中针对配置的每个所述展示位置所配置的运营信息，并在所述多次刷新执行完毕后，停止在推荐信息流中插入所述运营策略所配置的任意一个展示位置；

必出策略，用于通过所述运营策略针对多次刷新分别配置的至少一个展示位置，循环显示所述运营策略中针对配置的每个所述展示位置所配置的运营信息。

9.根据权利要求1所述的方法，其特征在于，当所述后续至少一次刷新是一次刷新，且当向所述客户端发送所述推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息时，所述方法还包括：

向所述客户端发送所述待应用运营策略的版本，以供所述客户端被再次刷新时，发送携带所述待应用运营策略的版本的新信息请求。

10.根据权利要求1所述的方法，其特征在于，当所述后续至少一次刷新是多次刷新，且在向所述客户端发送所述推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息之后，所述方法还包括：

接收所述客户端发送的推荐请求；其中，所述推荐请求是所述客户端被再次刷新时发送的，且后续的所述多次刷新未完成；

获取与所述目标对象对应的新推荐信息流；

向所述客户端发送所述新推荐信息流，以使所述客户端显示所述新推荐信息流，并在所述新推荐信息流中，插入所述待应用运营策略针对所述再次刷新所配置的至少一个展示位置，在插入的每个所述展示位置中显示对应配置的运营信息。

11.一种信息推荐方法，其特征在于，所述方法包括：

响应于针对客户端的刷新，向服务器发送针对目标对象的信息请求；其中，所述信息请求中携带用于供所述服务器进行查询操作的所述客户端的历史刷新数据以及已应用版本，所述已应用版本是所述客户端中应用的运营策略的版本；

接收所述服务器在进行所述查询操作后返回的推荐信息流、针对从所述刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对配置的每个所述展示位置所配置的运营信息；

显示所述推荐信息流，在所述推荐信息流中插入针对所述刷新所配置的至少一个展示位置，在插入的每个所述展示位置中显示对应配置的运营信息。

12.根据权利要求11所述的方法，其特征在于，当所述后续至少一次刷新是一次刷新，且在插入的每个所述展示位置中显示对应配置的运营信息之后，所述方法还包括：

响应于所述客户端被再次刷新，发送携带待应用运营策略的版本的新信息请求；

接收所述服务器返回的新推荐信息流、新待应用运营策略针对从所述再次刷新开始的后续至少一次刷新分别配置的至少一个新展示位置、以及针对配置的每个所述新展示位置所配置的新运营信息；其中，所述新待应用运营策略的版本是所述待应用运营策略的版本的后续更新版本；

显示所述新推荐信息流，在所述新推荐信息流中插入针对所述再次刷新所配置的至少一个新展示位置，在插入的每个所述新展示位置中显示对应配置的新运营信息。

13.根据权利要求11所述的方法，其特征在于，当所述后续至少一次刷新是多次刷新，且在插入的每个所述展示位置中显示对应配置的运营信息之后，所述方法还包括：

响应于针对所述客户端的再次刷新，向所述服务器发送推荐请求；其中，当所述再次刷新发生时所述多次刷新未完成；

接收所述服务器发送的所述目标对象对应的新推荐信息流；

显示所述新推荐信息流，并在所述新推荐信息流中，插入待应用运营策略针对所述再次刷新所配置的至少一个展示位置，在插入的每个所述展示位置中显示对应配置的运营信息。

14.一种信息推荐方法，其特征在于，所述方法包括：

响应于客户端被刷新，显示推荐信息流；

在所述推荐信息流中插入至少一个展示位置，并在插入的每个所述展示位置中显示对应配置的运营信息；

其中，针对多次所述刷新分别插入的至少一个展示位置，用于循环显示对应配置的运营信息，或者，在展示一遍对应配置的运营信息后隐藏。

15.一种信息推荐装置，其特征在于，所述装置包括：

接收模块，用于接收客户端发送的针对目标对象的信息请求；其中，所述信息请求是所述客户端被刷新时发送的，且携带所述客户端的历史刷新数据以及已应用版本，所述已应用版本是所述客户端中应用的运营策略的版本；

查询模块，用于基于所述历史刷新数据以及所述已应用版本进行查询操作，得到待应用运营策略中针对从所述刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息；

获取模块，用于获取与所述目标对象的特征适配的推荐信息流；

发送模块，用于向所述客户端发送所述推荐信息流、针对后续至少一次刷新分别配置的至少一个展示位置、以及针对每个所述展示位置所配置的运营信息，以供所述客户端进行刷新显示。

16.一种信息推荐装置，其特征在于，所述装置包括：

发送模块，用于响应于针对客户端的刷新，向服务器发送针对目标对象的信息请求；其中，所述信息请求中携带用于供所述服务器进行查询操作的所述客户端的历史刷新数据以及已应用版本，所述已应用版本是所述客户端中应用的运营策略的版本；

接收模块，用于接收所述服务器在进行所述查询操作后返回的推荐信息流、针对从所述刷新开始的后续至少一次刷新分别配置的至少一个展示位置、以及针对配置的每个所述展示位置所配置的运营信息；

显示模块，用于显示所述推荐信息流，在所述推荐信息流中插入针对所述刷新所配置的至少一个展示位置，在插入的每个所述展示位置中显示对应配置的运营信息。

17.一种信息推荐装置，其特征在于，所述装置包括：

显示模块，用于响应于客户端被刷新，显示推荐信息流；

插入模块，用于在所述推荐信息流中插入至少一个展示位置；

所述显示模块，还用于在插入的每个所述展示位置中显示对应配置的运营信息；

其中，针对多次所述刷新分别插入的至少一个展示位置，用于循环显示对应配置的运营信息，或者，在展示一遍对应配置的运营信息后隐藏。

18.一种电子设备，其特征在于，所述电子设备包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至10任一项、或权利要求11至13任一项、或权利要求14所述的信息推荐方法。

19.一种计算机可读存储介质，存储有可执行指令，其特征在于，所述可执行指令被处理器执行时实现权利要求1至10任一项、权利要求11至13任一项、或权利要求14所述的信息推荐方法。

20.一种计算机程序产品，包括计算机程序或指令，其特征在于，所述计算机程序或指令被处理器执行时实现权利要求1至10任一项、权利要求11至13任一项、或权利要求14所述的信息推荐方法。

Images