CN111105251A

CN111105251A - 一种信息推送方法及装置

Info

Publication number: CN111105251A
Application number: CN201811251802.4A
Authority: CN
Inventors: 李尧; 栗东晖; 刘艳丽
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2018-10-25
Filing date: 2018-10-25
Publication date: 2020-05-05

Abstract

本申请提供了一种信息推送方法及装置，其中，该方法包括：获取出行订单的订单信息；基于所述订单信息，确定与所述订单信息匹配的服务优惠信息；向发起所述出行订单的服务请求端推送所述服务优惠信息。上述方式中，通过结合行车订单中的订单信息，来选取合适的服务优惠信息并推荐给服务请求端，能够使得推荐的服务优惠信息与用户实际的服务需求更为匹配，提升服务优惠信息的使用率，避免服务优惠信息资源的浪费。

Description

一种信息推送方法及装置

技术领域

本申请涉及互联网技术领域，具体而言，涉及一种信息推送方法及装置。

背景技术

随着互联网的快速发展和普及，基于互联网进行网上交易的活动也越来越频繁，例如用户可以通过网上购物平台、网上打车平台、网上订餐平台等进行网上交易。各类网络平台为了提升自身竞争力，往往会向用户终端投放各类服务优惠信息，以提升用户访问量，促进交易量。

目前，网络平台在投放服务优惠信息时，往往是在用户打开终端上安装的客户端之后，在客户端的操作界面中展示服务优惠信息，并提示用户领取。但是，由于这些服务优惠信息都是预先配置好的，可能并不是用户真正有需求的服务优惠信息，导致这些服务优惠信息的使用率较低，并且，由于服务优惠信息并未准确投放给真正有需求的用户，这也造成了服务优惠信息资源的浪费。

发明内容

有鉴于此，本申请实施例的目的在于提供一种信息推送方法及装置，以提升服务优惠信息的使用率，避免服务优惠信息资源的浪费。

第一方面，本申请提供一种信息推送方法，包括：

获取出行订单的订单信息；

基于所述订单信息，确定与所述订单信息匹配的服务优惠信息；

向发起所述出行订单的服务请求端推送所述服务优惠信息。

一种可能的实施方式中，在向发起所述出行订单的服务请求端推送所述服务优惠信息之前，还包括：

确定所述出行订单的执行状态满足预设的推送条件。

一种可能的实施方式中，所述预设的推送条件包括以下条件中的至少一种：

所述出行订单执行结束且支付完成；

当前到达目标地点或在未来预设时长内到达目标地点；所述目标地点为所述出行订单的途径地或者目的地。

一种可能的实施方式中，向发起所述出行订单的服务请求端推送所述服务优惠信息，包括：

在向所述服务请求端返回的支付成功页面信息中携带所述服务优惠信息；或者，

在响应所述服务请求端的服务请求，向所述服务请求端返回的服务等待页面信息中携带所述服务优惠信息；或者，

在向所述服务请求端发送的订单进行页面信息中携带所述服务优惠信息。

一种可能的实施方式中，基于以下订单信息中的至少一种，确定与所述订单信息匹配的服务优惠信息：

订单支付费用；地点信息；订单类型。其中，所述地点信息中包括目标地点的服务类型。

一种可能的实施方式中，基于所述订单支付费用，确定匹配的服务优惠信息，包括：

根据所述订单支付费用，以及不同优惠金额的服务优惠信息分别对应的订单支付费用区间，确定与所述订单支付费用匹配的服务优惠信息。

一种可能的实施方式中，基于所述地点信息，确定匹配的服务优惠信息，包括：

确定与所述目标地点的服务类型匹配的服务优惠信息。

一种可能的实施方式中，基于所述订单类型，确定匹配的服务优惠信息，包括：

确定与所述订单类型匹配的服务优惠信息。

向所述服务请求端推送多条服务优惠信息。

一种可能的实施方式中，向所述服务请求端推送多条服务优惠信息，包括：

将所述多条服务优惠信息按照预设优先级顺序进行排列后推送给所述服务请求端。

一种可能的实施方式中，所述服务优惠信息包括优惠券、代金券、现金红包、折扣券中的一种或多种。

第二方面，本申请提供一种信息推送装置，包括：

获取模块，用于获取出行订单的订单信息；

第一确定模块，用于基于所述订单信息，确定与所述订单信息匹配的服务优惠信息；

推送模块，用于向发起所述出行订单的服务请求端推送所述服务优惠信息。

一种可能的设计中，所述装置还包括：

第二确定模块，用于在所述推送模块向发起所述出行订单的服务请求端推送所述服务优惠信息之前，确定所述出行订单的执行状态满足预设的推送条件。

一种可能的设计中，所述预设的推送条件包括以下条件中的至少一种：

所述出行订单执行结束且支付完成；

一种可能的设计中，所述推送模块，具体用于：

一种可能的设计中，所述第一确定模块基于以下订单信息中的至少一种，确定与所述订单信息匹配的服务优惠信息：

订单支付费用；地点信息；订单类型。其中，所述地点信息中包括目标地点的服务类型；

一种可能的设计中，所述第一确定模块，在基于所述订单支付费用，确定匹配的服务优惠信息时，具体用于：

一种可能的设计中，所述第一确定模块，在基于所述地点信息，确定匹配的服务优惠信息时，具体用于：

确定与所述目标地点的服务类型匹配的服务优惠信息。

一种可能的设计中，所述第一确定模块，在基于所述订单类型，确定匹配的服务优惠信息时，具体用于：

确定与所述订单类型匹配的服务优惠信息。

一种可能的设计中，所述推送模块，在向发起所述出行订单的服务请求端推送所述服务优惠信息时，具体用于：

向所述服务请求端推送多条服务优惠信息。

一种可能的设计中，所述推送模块，在向所述服务请求端推送多条服务优惠信息时，具体用于：

其中，上述各模块的功能可以参照上述第一方面中所涉及的说明，这里不再展开说明。

第三方面，本申请实施例还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面所述的信息推送方法的步骤。

第四方面，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面所述的信息推送方法的步骤。

本申请实施例中，通过获取行车订单中的订单信息，并基于订单信息来选择与订单信息匹配的服务优惠信息，进而推送给服务请求端。采用上述方式，结合行车订单中的订单信息，来选取合适的服务优惠信息并推荐给服务请求端，相比现有技术中推荐预先配置的服务优惠信息的方式，能够使得推荐的服务优惠信息与用户实际的服务需求更为匹配，提升服务优惠信息的使用率，避免服务优惠信息资源的浪费。

为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请的一些实施例的服务系统100的框图；

图2示出了本申请的一些实施例的电子设备200的示例性硬件和软件组件的示意图；

图3示出了本申请实施例提供的一种信息推送方法的流程示意图；

图4示出了本申请实施例提供的支付成功页面的展示效果示意图；

图5示出了本申请实施例提供的服务等待页面的展示效果示意图；

图6示出了本申请实施例提供的订单进行页面的展示效果示意图；

图7示出了本申请实施例提供的支付成功页面中展示多条服务优惠信息的效果示意图一；

图8示出了本申请实施例提供的支付成功页面中展示多条服务优惠信息的效果示意图二；

图9为本申请实施例提供的一种信息推送装置的结构示意图；

图10为本申请实施例提供的计算机设备100的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“打车场景下向用户推荐服务优惠信息”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕打车服务系统进行描述，但是应该理解，这仅是一个示例性实施例。本申请可以应用于任何其他交通运输类型的服务系统。例如，本申请可以应用于不同的运输系统环境，包括陆地，海洋，或航空等，或其任意组合。运输系统的交通工具可以包括出租车、私家车、顺风车、公共汽车、火车、子弹头列车、高速铁路、地铁、船只、飞机、宇宙飞船、热气球、或无人驾驶车辆等，或其任意组合。

本申请还可以包括能够向用户推荐服务优惠信息的任何服务系统，例如，网上购物平台中向用户推荐服务优惠信息的系统、网上订餐平台中向用户推荐服务优惠信息的系统等。当本申请应用到其它任何服务系统中时，同样可以从服务订单中获取订单信息并基于订单信息来推荐服务优惠信息。需要说明的是，不同服务系统中服务订单、以及对应的订单信息也有所区别，服务订单并不限于本申请下述实施例中示出的出行订单，还可以为购物订单、订餐订单等，相应地，订单信息也可以根据实际应用场景的不同而适应性改变。

并且，本申请中服务优惠信息包括但不限于优惠券，还可以为代金券、现金红包等，其中，服务优惠信息可适用的应用场景，包括但不限于打车、餐饮、电影、娱乐、住宿、机票、商场等应用场景。本申请中，针对某一服务系统来说，除了可以向该服务系统的服务请求端推送该服务系统能够使用的服务优惠信息，还可以向该服务系统的服务请求端推送其它服务系统上能够使用的服务优惠信息。例如，针对打车服务系统来说，可以向发起出行订单的服务请求端推送打车优惠券、也可以推送其它应用场景下适用的餐饮、电影、娱乐、住宿、机票、商场优惠券中的一种或多种。

本申请的系统或方法的应用可以包括网页、浏览器的插件、客户端终端、定制系统、内部分析系统、或人工智能机器人等，或其任意组合。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

本申请中的术语“乘客”、“请求方”、“服务请求方”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“司机”、“提供方”、“服务提供方”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务、提供服务或促成服务的提供的个人、实体或工具。本申请实施例中，用户例如可以是作为服务请求方的乘客、作为服务提供方的司机等，或其任意组合。并且，本申请的一些实施例中，“服务请求端”可以与“服务请求方终端”互换使用，“服务提供端”可以与“服务提供方终端”互换使用。

本申请的一个方面涉及一种服务系统。该系统在为服务请求端推荐服务优惠信息时，可以结合行车订单中的订单信息，来选取与订单信息匹配的服务优惠信息，然后将选取的服务优惠信息推荐给服务请求端。

值得注意的是，在本申请提出之前，目前服务系统在投放服务优惠信息时，往往是在服务请求端首次开启的操作界面中展示服务优惠信息，并且这些服务优惠信息都是预先配置好的，可能并不是用户真正有需求的服务优惠信息，故导致这些服务优惠信息的使用率较低，同时也造成了服务优惠信息资源的浪费。然而，本申请提供的信息推送方法，可以结合行车订单中的订单信息，来选取合适的服务优惠信息并推荐给服务请求端，相比现有方式，能够使得推荐的服务优惠信息与用户实际的服务需求更为匹配，可以提升服务优惠信息的使用率，并且能够有效避免服务优惠信息资源的浪费。

图1是本申请一些实施例的服务系统100的框图。例如，服务系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务系统100可以包括服务器110、网络120、服务请求方终端130、服务提供方终端140和数据库150中的一种或多种，服务器110中可以包括执行指令操作的处理器。

在一些实施例中，服务器110可以是单个服务器，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器110可以是分布式系统)。在一些实施例中，服务器110相对于终端，可以是本地的、也可以是远程的。例如，服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例，服务器110可以直接连接到服务请求方终端130、服务提供方终端140和数据库150中至少一个，以访问存储的信息和/或数据。在一些实施例中，服务器110可以在云平台上实现；仅作为示例，云平台可以包括私有云、公有云、混合云、社区云(community cloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合。在一些实施例中，服务器110可以在具有本申请中图2所示的一个或多个组件的电子设备200上实现。

在一些实施例中，电子设备200可以包括处理器220。处理器220可以处理与服务请求(本申请中，服务请求例如为携带有出行信息的打车请求，或支付出行订单的支付请求等)有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器220可以基于从服务请求方终端130获得的会话请求，与服务请求方终端130建立会话连接等。在一些实施例中，处理器220可以包括一个或多个处理核(例如，单核处理器(S)或多核处理器(S))。仅作为举例，处理器220可以包括中央处理单元(Central Processing Unit,CPU)、专用集成电路(Application Specific Integrated Circuit,ASIC)、专用指令集处理器(Application Specific Instruction-set Processor,ASIP)、图形处理单元(GraphicsProcessing Unit,GPU)、物理处理单元(Physics Processing Unit,PPU)、数字信号处理器(Digital Signal Processor,DSP)、现场可编程门阵列(Field Programmable GateArray,FPGA)、可编程逻辑器件(Programmable Logic Device,PLD)、控制器、微控制器单元、简化指令集计算机(Reduced Instruction Set Computing,RISC)、或微处理器等，或其任意组合。

网络120可以用于信息和/或数据的交换。在一些实施例中，服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140和数据库150)可以向其他组件发送信息和/或数据。例如，服务器110可以经由网络120从服务请求方终端130获取服务请求。在一些实施例中，网络120可以是任何类型的有线或者无线网络，或者是他们的结合。仅作为示例，网络130可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(Local Area Network，LAN)、广域网(Wide Area Network，WAN)、无线局域网(Wireless Local Area Networks，WLAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、公共电话交换网(Public Switched TelephoneNetwork，PSTN)、蓝牙网络、或近场通信(Near Field Communication，NFC)网络等，或其任意组合。在一些实施例中，网络120可以包括一个或多个网络接入点。例如，网络120可以包括有线或无线网络接入点，例如基站和/或网络交换节点，服务系统100的一个或多个组件可以通过该接入点连接到网络120以交换数据和/或信息。

在一些实施例中，服务请求方终端130的用户可以是服务实际需求者，也可以是除服务实际需求者之外的其他人。例如，服务请求方终端130的用户A可以使用服务请求方终端130来为服务实际需求者B发起服务请求(比如，用户A可以为自己的朋友B叫车)，或者从服务器110接收服务信息或指令等。在一些实施例中，服务提供方终端140的用户可以是服务实际提供者，也可以是除服务实际提供者之外的其他人。例如，服务提供方终端140的用户C可以使用服务提供方终端140接收由服务实际提供者D提供服务的服务请求(比如用户C可以为自己雇用的司机D接单)，和/或来自服务器110的信息或指令。

在一些实施例中，服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等，或其任意组合。在一些实施例中，移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，或其任意组合。在一些实施例中，智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等，或其任意组合。在一些实施例中，可穿戴设备可包括智能手环、智能鞋带、智能玻璃、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中，智能移动设备可以包括智能手机、个人数字助理(Personal Digital Assistant，PDA)、游戏设备、导航设备、或销售点(point of sale，POS)设备等，或其任意组合。在一些实施例中，虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等，或其任意组合。例如，虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中，机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中，服务请求方终端130可以是具有用于定位服务请求方和/或服务请求方终端的位置的定位技术的设备。

在一些实施例中，服务提供方终端140可以是与服务请求方终端130类似或相同的设备。在一些实施例中，服务提供方终端140可以是具有定位技术的设备，用于定位服务提供方和/或服务提供方终端的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以与其他定位设备通信以确定服务请求方、服务请求方终端130、服务提供方、或服务提供方终端140、或其任意组合的位置。在一些实施例中，服务请求方终端130和/或服务提供方终端140可以将定位信息发送给服务器110。

数据库150可以存储数据和/或指令。在一些实施例中，数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中，数据库150可以存储在本申请中描述的示例性方法的数据和/或指令。在一些实施例中，数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(Read-Only Memory,ROM)等，或其任意组合。作为举例，大容量存储器可以包括磁盘、光盘、固态驱动器等；可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等；易失性读写存储器可以包括随机存取存储器(Random Access Memory,RAM)；RAM可以包括动态RAM(Dynamic RandomAccess Memory,DRAM)，双倍数据速率同步动态RAM(Double Date-Rate Synchronous RAM,DDR SDRAM)；静态RAM(Static Random-Access Memory,SRAM)，晶闸管RAM(Thyristor-Based Random Access Memory,T-RAM)和零电容器RAM(Zero-RAM)等。作为举例，ROM可以包括掩模ROM(Mask Read-Only Memory,MROM)、可编程ROM(Programmable Read-OnlyMemory,PROM)、可擦除可编程ROM(Programmable Erasable Read-only Memory,PEROM)、电可擦除可编程ROM(Electrically Erasable Programmable read only memory,EEPROM)、光盘ROM(CD-ROM)、以及数字通用磁盘ROM等。在一些实施例中，数据库150可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等，或其任意组合。

在一些实施例中，数据库150可以连接到网络120以与服务系统100(例如，服务器110，服务请求方终端130，服务提供方终端140等)中的一个或多个组件通信。服务系统100中的一个或多个组件可以经由网络120访问存储在数据库150中的数据或指令。在一些实施例中，数据库150可以直接连接到服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140等)；或者，在一些实施例中，数据库150也可以是服务器110的一部分。

在一些实施例中，服务系统100中的一个或多个组件(例如，服务器110，服务请求方终端130，服务提供方终端140等)可以具有访问数据库150的权限。在一些实施例中，当满足一定条件时，服务系统100中的一个或多个组件可以读取和/或修改与服务请求方、服务提供方、或公众、或其任意组合有关的信息。例如，服务器110可以在接收服务请求之后读取和/或修改一个或多个用户的信息。作为另一示例，服务提供方终端140可以在从服务请求方终端130接收服务请求时访问与服务请求方有关的信息，但是服务提供方终端140可以不修改服务请求方的相关信息。

在一些实施例中，可以通过请求服务来实现服务系统100中的一个或多个组件的信息交换。服务请求的对象可以是任何产品。在一些实施方案中，产品可以是有形产品或非物质产品。有形产品可包括食品、药品、商品、化学产品、电器、服装、汽车、房屋、或奢侈品等，或其任意组合。非物质产品可以包括服务产品、金融产品、知识产品、或互联网产品等，或其任意组合。互联网产品可以包括单独的主机产品、网络产品、移动互联网产品、商业主机产品、或嵌入式产品等，或其任意组合。互联网产品可以用在移动终端的软件、程序、或系统等，或者它们的任意组合中。移动终端可以包括平板电脑、笔记本电脑、移动电话、个人数字助理(Personal Digital Assistant,PDA)、智能手表、销售点(Point of sales,POS)设备、车载电脑、车载电视、或可穿戴设备等，或其任意组合。例如，互联网产品可以是计算机或移动电话中使用的任何软件和/或应用程序。软件和/或应用程序可以涉及社交、购物、运输、娱乐时间、学习、或投资等，或其任意组合。在一些实施例中，与运输有关的软件和/或应用程序可以包括旅行软件和/或应用程序、车辆调度软件和/或应用程序、绘图软件和/或应用程序等。在车辆调度软件和/或应用程序中，车辆可包括马、马车、人力车(例如，独轮车、自行车、三轮车等)、汽车(例如，出租车、公共汽车、私家车等)、火车、地铁、船只、飞机(例如，飞机、直升机、航天飞机、火箭、热气球等)等，或其任意组合。

图2示出根据本申请的一些实施例的可以实现本申请思想的服务器110、服务请求方终端130、服务提供方终端140的电子设备200的示例性硬件和软件组件的示意图。例如，处理器220可以用于电子设备200上，并且用于执行本申请中的功能。

电子设备200可以是通用计算机或特殊用途的计算机，两者都可以用于实现本申请的问题推荐方法。本申请尽管仅示出了一个计算机，但是为了方便起见，可以在多个类似平台上以分布式方式实现本申请描述的功能，以均衡处理负载。

例如，电子设备200可以包括连接到网络的网络端口210、用于执行程序指令的一个或多个处理器220、通信总线230、和不同形式的存储介质240，例如，磁盘、ROM、或RAM，或其任意组合。示例性地，计算机平台还可以包括存储在ROM、RAM、或其他类型的非暂时性存储介质、或其任意组合中的程序指令。根据这些程序指令可以实现本申请的方法。电子设备200还包括计算机与其他输入输出设备(例如键盘、显示屏)之间的输入/输出(Input/Output，I/O)接口250。

为了便于说明，在电子设备200中仅描述了一个处理器。然而，应当注意，本申请中的电子设备200还可以包括多个处理器，因此本申请中描述的一个处理器执行的步骤也可以由多个处理器联合执行或单独执行。例如，若电子设备200的处理器执行步骤A和步骤B，则应该理解，步骤A和步骤B也可以由两个不同的处理器共同执行或者在一个处理器中单独执行。例如，第一处理器执行步骤A，第二处理器执行步骤B，或者第一处理器和第二处理器共同执行步骤A和B。

结合上述对服务系统以及服务系统中各电子设备的描述，下面结合具体实施例，对本申请提供的信息推送方法进行详细说明。

实施例一

参照图3所示，为本申请实施例提供的一种信息推送方法的流程示意图，该信息推送方法可以由图1所述的服务系统中的服务器来执行，具体执行过程包括如下步骤：

步骤301、获取出行订单的订单信息。

本申请实施例中，在服务请求端向服务器发起出行请求的过程中，服务器可以基于出行请求中携带的乘车信息，生成出行订单，进而服务器可以监控出行订单的状态，并获取出行订单的订单信息。

具体的，订单信息可以包括但不限于以下信息：订单支付费用；地点信息；订单类型。其中，地点信息中例如可以包括目标地点的服务类型，目标地点可以理解为能够使用服务优惠信息的地点，而能够使用服务信息的地点既可以为出行订单中的途径地，也可以为出行订单中的目的地，本申请对此并不限定。

步骤302、基于订单信息，确定与订单信息匹配的服务优惠信息。

一种可能的实施方式中，图1所示的服务系统的数据库中可以预先存储有服务优惠信息集合，服务优惠信息集合例如包括多条服务优惠信息、以及每条服务优惠信息的使用信息，其中，使用信息包括优惠金额、优惠类型。具体的，优惠类型可以根据服务优惠信息可适用的应用场景来划分，多条服务优惠信息并不限于在打车应用场景下可使用的打车优惠信息，还可以在其它应用场景下可使用的餐饮优惠信息、住宿优惠信息等。另外，优惠类型也可以根据服务优惠信息适用的订单类型来划分。其中，服务优惠信息包括但不限于优惠券、代金券、现金红、折扣券等。

服务器在确定与订单信息匹配的服务优惠信息时，可以基于服务优惠信息集合中记录的每条服务优惠信息的使用信息，将服务优惠信息集合中的服务优惠信息分别与订单信息进行匹配，以得到与订单信息匹配的服务优惠信息。

另一种可能的实施方式中，对于其它应用场景下可使用的服务优惠信息，这类服务优惠信息并不一定都预先存储在服务优惠信息集合中，还可以存储在其它应用场景对应的服务系统的数据库中。服务器在确定与订单信息匹配的服务优惠信息时，也可以通过与其它服务系统建立通信连接，从其它服务系统上获取得到服务优惠信息，进而分别与订单信息进行匹配，以得到与订单信息匹配的服务优惠信息。

本申请实施例中，由于订单信息中包括订单支付费用、地点信息、订单类型中的一种或多种，故在确定匹配的服务优惠信息时，可以针对订单信息中包括的每一种信息来分别确定匹配的服务优惠信息，也可以将订单信息中包括的一种或多种信息相结合来确定匹配的服务优惠信息。其中，结合订单信息来匹配服务优惠信息的具体过程，将在后文中展开说明，这里暂不说明。

步骤303、向发起出行订单的服务请求端推送服务优惠信息。

本申请实施例中，服务器在将订单信息与服务优惠信息进行匹配时，可以判断是否存在与当前的出行订单的订单信息匹配的服务优惠信息。一种可能的实施方式中，服务器在判断出存在与当前的出行订单的订单信息匹配的服务优惠信息之后，可以向发起当前的出行订单的服务请求端推送匹配的服务优惠信息。这一推送过程，可以理解为即时推送的过程，即服务器在确定出存在匹配的服务优惠信息后立即推送给服务请求端。

另一种可能的实施方式中，服务器可以监测出行订单的执行状态，在判断出存在与当前的出行订单的订单信息匹配的服务优惠信息之后，进一步可以判断出行订单的执行状态是否满足预设的推送条件，在判断出订单的执行状态满足预设的推送条件之后，再将匹配的服务优惠信息推送给服务请求端。

具体的，当出行订单的执行状态符合以下至少一种状态时，确定出行订单的执行状态满足预设的推送条件：

状态一、出行订单执行结束且支付完成。

具体的，服务器可以在接收到服务提供端发送的订单结束指令时，确定出行订单执行结束。其中，订单结束指令可以是服务提供端在基于定位信息检测到已到达目的地时自动发送给服务器的，或者，也可以是由司机通过点击订单进行页面中的订单结束按钮，来触发服务提供端发送给服务器的。

进一步地，服务器在确定出行订单执行结束后，可以向服务请求端推送订单支付费用的支付页面信息，以使服务请求端展示支付页面，提示乘客支付本次行车订单的费用。服务器在接收到服务提供端发送的支付完成指令时，可以确定出行订单支付完成。另外，当服务请求端已配置了自动支付功能时，服务器可以在确定出行订单执行结束后，直接从服务请求端的账户中自动扣款，扣款成功后，确定出行订单支付完成。

状态二、当前到达目标地点或在未来预设时长内到达目标地点。

其中，目标地点可以为出行订单的途径地或者目的地，并且，在目标地点处存在能够使用的服务优惠信息。

具体实施中，服务器在针对行车订单生成导航路径之后，可以确定导航路径中可能经过的能够使用服务优惠信息的目标地点。在出行订单处于订单进行状态中，服务器可以监控服务提供端所处的位置，当监测到服务提供端所处的位置到达目标地点时，向服务请求端推送目标地点处能够使用的服务优惠信息；或者，当监测到服务提供端所处的位置距离目标地点在预设距离范围内时，向服务请求端推送目标地点处能够使用的服务优惠信息；或者，基于服务提供端所处的位置与目标地点之间的距离，预估服务提供端到达目标地点的时长，当监测到预估出的时长小于上述未来预设时长时，向服务请求端推送目标地点处能够使用的服务优惠信息。

本申请实施例中，鉴于出行订单的执行状态的不同，服务器在确定出行订单的执行状态满足预设的推送条件后，向服务请求端推送服务优惠信息的过程包括以下几种方式：

方式一、在向服务请求端返回的支付成功页面信息中携带服务优惠信息。

具体的，当服务器确定出行订单支付成功之后，可以向服务请求端返回支付成功页面信息，进而服务请求端可以基于支付成功页面信息，在操作界面中显示支付成功页面，其中，支付成功页面中展示服务优惠信息。

例如，参照图4所示的支付成功页面的展示效果示意图，支付成功页面包括用于展示支付状态的提示窗口，支付状态显示为“支付成功”、以及出行订单的订单支付费用为“20元”。支付成功页面还包括服务优惠信息领取窗口，用来展示服务优惠信息1至服务优惠信息n。

方式二、在响应服务请求端的服务请求，向服务请求端返回的服务等待页面信息中携带服务优惠信息。

以打车应用场景为例，服务请求例如为服务请求端发送的出行请求。服务器在接收到携带有订单信息的出行请求发送给服务器之后，可以生成出行订单，进而将出行订单分配给能够提供出行服务的服务提供端。其中，在服务器分配出行订单的过程中，可以向服务请求端反馈服务等待页面信息。本申请实施例中，在向服务请求端返回的服务等待页面信息中可以携带服务优惠信息。相应地，服务请求端在接收到携带有服务优惠信息的服务等待页面信息之后，可以在操作界面中展示服务等待页面，以提示乘客目前正在派单。

例如，参照图5所示的服务等待页面的展示效果示意图，服务等待页面包括用于展示派单情况的窗口，其上可以展示由乘车起始位置P至目的地Q之间的导航路径(如图5所示的曲线)，目前等待派单的人数、以及预估等待时长等。服务等待页面还可以包括服务优惠信息领取窗口，用来展示服务优惠信息1至服务优惠信息n。

方式三、在向服务请求端发送的订单进行页面信息中携带服务优惠信息。

以打车应用场景为例，服务器在将出行订单成功分配给能够提供出行服务的服务提供端之后，可以向服务请求端发送订单进行页面信息，其中，携带有服务优惠信息。相应地，服务请求端可以基于订单进行页面信息，展示订单进行页面。

例如，参照图6所示的订单进行页面的展示效果示意图，订单进行页面包括用于展示订单进行状态的窗口，其上可以展示行车订单中由乘车起始位置P至目的地Q的导航路径、当前定位位置M、预估到达时间、以及预估订单支付费用等。订单进行页面还可以包括服务优惠信息领取窗口，用来展示服务优惠信息1至服务优惠信息n。

上述方式一至方式三中，服务器向服务请求端推送的服务优惠信息可以有至少一条。当服务优惠信息有多条时，服务器可以将多条服务优惠信息按照预设优先级顺序进行排列后推送给服务请求端。相应地，在服务优惠信息领取窗口中展示的服务优惠信息可以按照预设优先级顺序进行排列展示。

一示例中，预设优先级顺序可以以服务优惠信息的优惠金额的大小来设定，例如，将优惠金额越大的服务优惠信息的优先级设置的高一些，将优惠金额越小的服务优惠信息的优先级设置的低一些。这样，按照预设优先级顺序排序得到的服务优惠信息，即为按照优惠金额由大到小的顺序进行排序得到的服务优惠信息。例如，图7所示的支付成功页面中展示多条服务优惠信息的效果示意图一，假设服务优惠信息包括优惠券A、优惠券A的优惠金额为5元，优惠券B、优惠券B的优惠金额为10元，优惠券C、优惠券C的优惠金额为10元，那么，服务优惠信息领取窗口中由上至下依次展示优惠券A、优惠券B、优惠券C。

另一示例中，预设优先级顺序可以根据服务优惠信息对应的服务类型来设定。一种可能的配置中，可以将与打车服务匹配度较高的优惠券的优先级设置的高一些，可以将与打车服务匹配度较低的优惠券的优先级设置的低一些。例如，图8所示的支付成功页面中展示多条服务优惠信息的效果示意图二，假设服务优惠信息包括乘车优惠券、餐饮优惠券、住宿优惠券。那么，服务优惠信息领取窗口中由上至下依次展示乘车优惠券、餐饮优惠券、住宿优惠券。

此外，服务优惠信息领取窗口中展示的每一种服务优惠信息可以配置一个对应的触发按钮，当触发按钮被触发时，可以确定该触发按钮对应的服务优惠信息被领取成功。另一种可能的配置中，服务优惠信息的领取窗口中还可以展示一个一键领取的触发按钮，当一键领取的触发按钮被触发时，可以确定服务优惠信息的领取窗口中展示的全部服务优惠信息被领取成功。

实施例二

本实施例二中，主要对基于订单信息来匹配服务优惠信息的具体过程进行详细说明。

首先，对订单信息中包括的信息进行介绍。

(1)订单支付费用。

本申请实施例中，当出行订单在处于不同的状态时，获取到的订单支付费用可能存在区别。例如，当出行订单处于订单进行中时，订单支付费用可以是服务器基于乘车起始位置和乘车终止位置之间的导航路径、以及预估行驶时间而预估出的预估订单支付费用。再例如，当出行订单处于订单结束状态时，订单支付费用可以是服务器基于乘车起始位置和乘车终止位置之间的实际行驶路径、以及实际行驶时间而计算出的实际订单支付费用。

(2)地点信息。

本申请实施例中，地点信息可以包括目标地点的服务类型。目标地点可以理解为能够使用服务优惠信息的地点，而能够使用服务信息的地点既可以为出行订单中的途径地，也可以为出行订单中的目的地，本申请对此并不限定。目标地点的服务类型可以理解为目标地点所在的服务场所能够提供的服务的类型，服务类型包括但不限于餐饮、娱乐、住宿、交通等服务。并且，同一目标地点具备的服务类型可以为一种或多种。

例如，当出行订单中的目的地为某一机场或高铁站时，可以确定目标地点为某一机场或高铁站，目标地点的服务类型包括交通服务，另外考虑到机场或高铁站中也设有很多餐饮店铺，因此目标地点的服务类型还可以包括餐饮服务等。

其中，考虑到在电子地图中，对于某地点一般采用兴趣点(Point of Interest，POI)的形式来表达和存储，故本申请实施例中，目标地点例如可以采用电子地图数据中的POI数据来表示。每个POI数据一般包括经纬度、POI名称、POI地址、POI属性等字段。那么，目标地点的服务类型可以从POI数据中获取，例如从POI属性中获取。

另外，地点信息还可以采用自定义的数据格式，例如可以根据乘客历史乘车记录、其他网站数据、用户点评等信息，生成地点信息，其中，地点信息例如包括地点名称、地址、类型等。

(3)订单类型。

本申请实施例中，以订单为行车订单为例，那么订单类型例如可以为用车类型，其中，用车类型可以是服务请求端发起出行请求时由服务请求方选择的。一示例中，用车类型可以分为出租车、快车、专车、豪华车、顺风车等。另一示例中，用车类型可以分为拼车、单独乘车等。

当然，实际应用中订单信息还可以包括其它能够反映出服务请求端发起的出行订单的特点的个性化信息，例如，出行订单的结束时刻等，本申请对此并不限定。

进一步地，考虑到获取到的订单信息分为多种情况，故在基于订单信息来确定匹配的服务优惠信息时，也可以分为如下几种情况：

情况一：当订单信息中包括订单支付费用时，基于订单支付费用，确定匹配的服务优惠信息，可以为：

根据订单支付费用，以及不同优惠金额的服务优惠信息分别对应的订单支付费用区间，确定与订单支付费用匹配的优惠券金额。

这里，可以预先记录不同金额的服务优惠信息可适用的订单支付费用区间。例如，参照表1示例性给出的服务优惠信息的优惠金额与订单支付费用区间之间的对应关系：

表1

优惠金额/元	订单支付费用M区间/元
		5	20≤M＜40
10	40≤M＜60
		20	60≤M＜80
30	M≥80

由表1所示，当服务请求端支付的订单支付费用在20元至40元之间时，服务器可以向服务请求端推送优惠金额为5元的服务优惠信息。

情况二：当订单信息中包括地点信息，地点信息中包括目标地点的服务类型时，那么，基于地点信息，确定匹配的服务优惠信息，可以为：

确定与目标地点的服务类型匹配的服务优惠信息。

一种可能的实施方式中，可以预先区分每条服务优惠信息归属的优惠类型，每一种优惠类型可表示服务优惠信息可适用的应用场景，应用场景例如包括打车场景、餐饮场景、交通场景、商场场景等中的一种或多种。在确定匹配的服务优惠信息时，可以将不同服务优惠信息的优惠类型分别与目标地点的服务类型进行匹配，进而确定出与目标地点的服务类型匹配的服务优惠信息。

一示例中，当目标地点为某一机场或高铁站时，可以确定目标地点的服务类型为交通服务，那么可以确定出与目标地点的服务类型匹配的服务优惠信息为交通服务。

情况三：当订单信息中包括用车类型时，那么，基于订单类型，确定匹配的服务优惠信息，可以为：

确定与订单类型匹配的服务优惠信息。

一种可能的实施方式中，以订单类型为用车类型为例，可以预先区分每条服务优惠信息的优惠类型，每一种优惠类型可表示服务优惠信息可适用的用车类型，用车类型例如包括出租车、快车、专车、豪华车、顺风车中的一种或多种。在确定匹配的服务优惠信息时，可以将不同服务优惠信息可适用的用车类型分别与订单信息中的用车类型进行匹配，进而确定出与订单信息中的用车类型匹配的服务优惠信息。

一示例中，当订单信息中包括的用车类型为出租车时，可以确定出可适用在出租车服务中的服务优惠信息，为与订单信息中的用车类型匹配的服务优惠信息。

需要说明的是，为便于对本方案的理解，上述实施例中是针对每一种订单信息分别介绍了确定匹配的服务优惠信息的过程，但是，实际应用中，也可以将上述情况一至情况三中的一种或多种相结合，确定匹配的服务优惠信息。

例如，继续沿用情况二中的示例，在确定出与目标地点的服务类型匹配的服务优惠信息为交通服务之后，还可以结合情况一中订单支付费用与优惠券金额之间的匹配过程，从交通服务类的服务优惠信息中选取优惠金额与订单支付费用匹配的服务优惠信息。

再例如，继续沿用情况三中的示例，还可以结合情况一中订单支付费用与优惠金额之间的匹配过程，从可适用在出租车服务中的服务优惠信息中选取优惠金额与订单支付费用匹配的服务优惠信息。

上述实施例中，通过获取行车订单中的订单信息，并基于订单信息来选择与订单信息匹配的服务优惠信息，进而推送给服务请求端。采用上述方式，结合行车订单中的订单信息，来选取合适的服务优惠信息并推荐给服务请求端，相比现有技术中推荐预先配置的服务优惠信息的方式，能够使得推荐的服务优惠信息与用户实际的服务需求更为匹配，提升服务优惠信息的使用率，避免服务优惠信息资源的浪费。

基于同一技术构思，本申请实施例中还提供了与信息推送方法对应的信息推送装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述信息推送方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图9所示，为本申请实施例提供的一种信息推送装置的结构示意图，所述装置90包括：

获取模块91，用于获取出行订单的订单信息；

第一确定模块92，用于基于所述订单信息，确定与所述订单信息匹配的服务优惠信息；

推送模块93，用于向发起所述出行订单的服务请求端推送所述服务优惠信息。

一种可能的设计中，所述装置还包括：

第二确定模块94，用于在所述推送模块向发起所述出行订单的服务请求端推送所述服务优惠信息之前，确定所述出行订单的执行状态满足预设的推送条件。

所述出行订单执行结束且支付完成；

一种可能的设计中，所述推送模块93，具体用于：

一种可能的设计中，所述第一确定模块92基于以下订单信息中的至少一种，确定与所述订单信息匹配的服务优惠信息：

订单支付费用；地点信息；订单类型。

一种可能的设计中，所述地点信息中包括目标地点的服务类型。

一种可能的设计中，所述第一确定模块92，在基于所述订单支付费用，确定匹配的服务优惠信息时，具体用于：

一种可能的设计中，所述第一确定模块92，在基于所述地点信息，确定匹配的服务优惠信息时，具体用于：

确定与所述目标地点的服务类型匹配的服务优惠信息。

一种可能的设计中，所述第一确定模块92，在基于所述订单类型，确定匹配的服务优惠信息时，具体用于：

确定与所述订单类型匹配的服务优惠信息。

一种可能的设计中，所述推送模块93，在向发起所述出行订单的服务请求端推送所述服务优惠信息时，具体用于：

向所述服务请求端推送多条服务优惠信息。

一种可能的设计中，所述推送模块93，在向所述服务请求端推送多条服务优惠信息时，具体用于：

本申请实施例中，上述各模块的具体功能和交互方式，可参见图3至图8对应的实施例的记载，在此不再赘述。

基于相同的技术构思，本申请实施例还提供了一种计算机设备。参照图10所示，为本申请实施例提供的计算机设备100的结构示意图，包括处理器101、存储器102、和总线103。其中，存储器102用于存储执行指令，包括内存1021和外部存储器1022；这里的内存1021也称内存储器，用于暂时存放处理器101中的运算数据，以及与硬盘等外部存储器1022交换的数据，处理器101通过内存1021与外部存储器1022进行数据交换，当计算机设备100运行时，处理器101与存储器102之间通过总线103通信，使得处理器101在执行以下指令：

获取出行订单的订单信息；

向发起所述出行订单的服务请求端推送所述服务优惠信息。

一种可能的实施方式中，处理器101在向发起所述出行订单的服务请求端推送所述服务优惠信息之前，可以确定所述出行订单的执行状态满足预设的推送条件。

所述出行订单执行结束且支付完成；

一种可能的实施方式中，处理器101在向发起所述出行订单的服务请求端推送所述服务优惠信息时，具体可以为：在向所述服务请求端返回的支付成功页面信息中携带所述服务优惠信息；或者，在响应所述服务请求端的服务请求，向所述服务请求端返回的服务等待页面信息中携带所述服务优惠信息；或者，在向所述服务请求端发送的订单进行页面信息中携带所述服务优惠信息。

一种可能的实施方式中，处理器101可以基于以下订单信息中的至少一种，确定与所述订单信息匹配的服务优惠信息：

一种可能的实施方式中，处理器101在基于所述订单支付费用，确定匹配的服务优惠信息时，可以根据所述订单支付费用，以及不同优惠金额的服务优惠信息分别对应的订单支付费用区间，确定与所述订单支付费用匹配的服务优惠信息。

一种可能的实施方式中，处理器101在基于所述地点信息，确定匹配的服务优惠信息时，可以确定与所述目标地点的服务类型匹配的服务优惠信息。

一种可能的实施方式中，处理器101在基于所述订单类型，确定匹配的服务优惠信息时，可以确定与所述订单类型匹配的服务优惠信息。

一种可能的实施方式中，处理器101向发起所述出行订单的服务请求端推送所述服务优惠信息时，可以向所述服务请求端推送多条服务优惠信息。

一种可能的实施方式中，处理器101在向所述服务请求端推送多条服务优惠信息时，可以将所述多条服务优惠信息按照预设优先级顺序进行排列后推送给所述服务请求端。

其中，处理器101的具体处理流程可以参照图3至图8对应的实施例的记载，这里不再赘述。

本申请提供的上述方法、装置及设备，可以结合行车订单中的订单信息，来选取合适的服务优惠信息并推荐给服务请求端，相比现有技术中推荐预先配置的服务优惠信息的方式，能够使得推荐的服务优惠信息与用户实际的服务需求更为匹配，提升服务优惠信息的使用率，避免服务优惠信息资源的浪费。

基于相同的技术构思，本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述信息推送方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述信息推送方法，以更好地满足不同请求端的用户的咨询需求，减少用户在咨询问题时的等待时长，提高咨询问题的效率。

基于相同的技术构思，本申请实施例还提供了一种计算机程序产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行上述信息推送方法的步骤，具体实现可参见上述方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims

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

获取出行订单的订单信息；

向发起所述出行订单的服务请求端推送所述服务优惠信息。

2.如权利要求1所述的方法，其特征在于，向发起所述出行订单的服务请求端推送所述服务优惠信息之前，还包括：

确定所述出行订单的执行状态满足预设的推送条件。

3.如权利要求2所述的方法，其特征在于，所述预设的推送条件包括以下条件中的至少一种：

所述出行订单执行结束且支付完成；

4.如权利要求1所述的方法，其特征在于，向发起所述出行订单的服务请求端推送所述服务优惠信息，包括：

5.如权利要求1所述的方法，其特征在于，基于以下订单信息中的至少一种，确定与所述订单信息匹配的服务优惠信息：

订单支付费用；地点信息；订单类型。

6.如权利要求5所述的方法，其特征在于，所述地点信息包括目标地点的服务类型。

7.如权利要求5所述的方法，其特征在于，基于所述订单支付费用，确定匹配的服务优惠信息，包括：

8.如权利要求5所述的方法，其特征在于，基于所述地点信息，确定匹配的服务优惠信息，包括：

确定与所述目标地点的服务类型匹配的服务优惠信息。

9.如权利要求5所述的方法，其特征在于，基于所述订单类型，确定匹配的服务优惠信息，包括：

确定与所述订单类型匹配的服务优惠信息。

10.如权利要求1所述的方法，其特征在于，向发起所述出行订单的服务请求端推送所述服务优惠信息，包括：

向所述服务请求端推送多条服务优惠信息。

11.如权利要求10所述的方法，其特征在于，向所述服务请求端推送多条服务优惠信息，包括：

12.如权利要求1至11任一所述的方法，其特征在于，所述服务优惠信息包括优惠券、代金券、现金红包、折扣券中的一种或多种。

13.一种信息推送装置，其特征在于，包括：

获取模块，用于获取出行订单的订单信息；

14.如权利要求13所述的装置，其特征在于，所述装置还包括：

15.如权利要求14所述的装置，其特征在于，所述预设的推送条件包括以下条件中的至少一种：

所述出行订单执行结束且支付完成；

16.如权利要求13所述的装置，其特征在于，所述推送模块，具体用于：

17.如权利要求13所述的装置，其特征在于，所述第一确定模块基于以下订单信息中的至少一种，确定与所述订单信息匹配的服务优惠信息：

订单支付费用；地点信息；订单类型。

18.如权利要求17所述的装置，其特征在于，所述地点信息中包括目标地点的服务类型。

19.如权利要求17所述的装置，其特征在于，所述第一确定模块，在基于所述订单支付费用，确定匹配的服务优惠信息时，具体用于：

20.如权利要求17所述的装置，其特征在于，所述第一确定模块，在基于所述地点信息，确定匹配的服务优惠信息时，具体用于：

确定与所述目标地点的服务类型匹配的服务优惠信息。

21.如权利要求17所述的装置，其特征在于，所述第一确定模块，在基于所述订单类型，确定匹配的服务优惠信息时，具体用于：

确定与所述订单类型匹配的服务优惠信息。

22.如权利要求13所述的装置，其特征在于，所述推送模块，在向发起所述出行订单的服务请求端推送所述服务优惠信息时，具体用于：

向所述服务请求端推送多条服务优惠信息。

23.如权利要求22所述的装置，其特征在于，所述推送模块，在向所述服务请求端推送多条服务优惠信息时，具体用于：

24.如权利要求13至23任一所述的装置，其特征在于，所述服务优惠信息包括优惠券、代金券、现金红包、折扣券中的一种或多种。

25.一种电子设备，其特征在于，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如权利要求1至12任一所述的信息推送方法的步骤。

26.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至12任一所述的信息推送方法的步骤。