CN112017001A - 网约车车型推荐方法、装置、电子设备和存储介质 - Google Patents

Abstract

本申请提供了一种网约车车型推荐方法、装置、电子设备和存储介质，通过获取待响应用户选择的上车地点及服务请求时间，获取在服务请求时间之前，且在上车地点的预设距离范围内的排队订单的数量，根据排队订单的数量在待响应用户的预订单中推荐目标车型，从而使得待响应用户的预订单发布后，可以被目标车型响应，从而加快待响应用户的订单的响应速度，提升用户体验。

Description

网约车车型推荐方法、装置、电子设备和存储介质

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种网约车车型推荐方法、装置、电子设备和存储介质。

背景技术

目前，随着交通的日趋便利，网约车出行已经成为人们常用的出行方式，呼叫网约车的方式往往为通过相关的网约车应用程序直接发起订单，由服务器对订单进行处理，并为用户分配合适的网约车。

在早晚高峰期、下雨等时段，对于网约车的需求较大，此时呼叫网约车的订单较多，容易出现供需失衡的情况，导致对订单响应较慢。

发明内容

有鉴于此，本申请的目的在于提供一种网约车车型推荐方法、装置、电子设备和存储介质，通过为用户推荐车型，从而提升在早晚高峰期、下雨等时段订单的响应速度。

第一方面，本发明实施例提供一种网约车车型推荐方法，包括：

获取待响应用户选择的上车地点及服务请求时间；

获取在所述服务请求时间之前，在所述上车地点的预设距离范围内的排队订单的数量；

根据所述排队订单的数量、上车地点及所述服务请求时间生成预订单；

根据所述排队订单的数量在所述待响应用户的预订单中推荐目标车型。

在可选的实施方式中，所述根据所述排队订单的数量在所述待响应用户的预订单中推荐目标车型，包括：

判断所述排队订单的数量是否大于第一预设值；

若所述排队订单的数量大于所述第一预设值，则从所述待响应用户的历史订单中获取第一目标订单及第二目标订单，其中，所述第一目标订单为最近一次发布且在发布时排队订单的数量大于所述第一预设值的历史订单，所述第二目标订单为所述待响应用户最近一次发布的历史订单；

根据所述待响应用户在发布所述第一目标订单和所述第二目标订单时选择的车型在该待响应用户的所述预订单中推荐相应的目标车型。

在可选的实施方式中，所述方法还包括：

若所述排队订单的数量不大于所述第一预设值，则从所述待响应用户的历史订单中获取所述第二目标订单；

根据所述待响应用户在发布所述第二目标订单时选择的车型在该待响应用户的所述预订单中推荐相应的目标车型。

在可选的实施方式中，所述方法还包括：

判断推荐的目标车型的数量是否达到第二预设值；

若未达到所述第二预设值，则将所述目标车型的数量补齐至所述第二预设值。

在可选的实施方式中，所述将所述目标车型的数量补齐至所述第二预设值，包括：

计算所述待响应用户在预设时间范围内的历史订单中选择的车型的次数；

按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，直至所述目标车型的数量达到第二预设值。

在可选的实施方式中，所述将所述目标车型的数量补齐至第二预设值，包括：

计算在所述服务请求时间的预设时间范围内且在所述上车地点的预设距离范围内的其他用户的订单信息中，各个车型被选择的次数；

按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，直至所述目标车型的数量达到第二预设值。

在可选的实施方式中，按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，包括：

按照各所述车型中不是目标车型的备用推荐车型被选择的次数从多到少的顺序，将所述备用推荐车型依次添加为目标车型。

第二方面，本发明实施例提供一种网约车车型推荐装置，包括：

第一获取模块，用于获取待响应用户选择的上车地点及服务请求时间；

第二获取模块，用于获取在所述服务请求时间之前，在所述上车地点的预设距离范围内的排队订单的数量；

预订单生成模块，用于根据所述排队订单的数量、上车地点及所述服务请求时间生成预订单；

车型推荐模块，用于根据所述排队订单的数量在所述待响应用户的预订单中推荐目标车型。

第三方面，本发明实施例提供一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行如前述实施方式任一所述方法的步骤。

第四方面，本发明实施例提供一种存储介质，所述存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行如前述实施方式任一所述方法的步骤。

本申请实施例提供的网约车车型推荐方法、装置、电子设备和存储介质，通过获取待响应用户选择的上车地点及服务请求时间，获取在服务请求时间之前，且在上车地点的预设距离范围内的排队订单的数量，根据排队订单的数量在待响应用户的预订单中推荐目标车型，从而使得待响应用户的预订单发布后，可以被目标车型响应，从而加快待响应用户的订单的响应速度，提升用户体验。

附图说明

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

图1为本申请涉及的网约车服务系统的示意图；

图2为本申请实施例提供的网约车车型推荐方法的流程图之一；

图3为本申请实施例提供的预订单页面示意图；

图4为本申请实施例提供的步骤S104的子步骤流程图；

图5为本申请实施例提供的网约车车型推荐方法的流程图之二；

图6为本申请实施例提供的步骤S106的子步骤流程图之一；

图7为本申请实施例提供的步骤S106的子步骤流程图之二；

图8为本申请实施例提供的网约车车型推荐装置的功能模块图；

图9为本申请实施例提供的电子设备的示意图。

图标：100-网约车服务系统；110-服务器；120-网络；130-乘客终端；140-司机终端；150-数据库；10-电子设备；11-处理器；12-存储器；13-总线；200-网约车车型推荐装置；210-第一获取模块；220-第二获取模块；230-预订单生成模块；240-车型推荐模块；250-数量判断模块；260-车型补齐模块。

具体实施方式

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

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

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

本申请中的术语“用户”、“乘客”、“请求方”、“服务请求方”和“客户”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术“司机”、“提供方”、“服务提供方”和“供应商”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务的个人、实体或工具。在本申请中，“用户”和“乘客终端可以互换使用，“驾驶员”和“驾驶员终端”可以互换使用。

本申请中的术语“服务请求”和“订单”可互换使用，以指代由乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合发起的请求。接受该“服务请求”或“订单”的可以是乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合。服务请求可以是收费的或免费的。

请参照图1，图1为本申请涉及的网约车服务系统100的示意图，网约车服务系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。网约车服务系统100可以包括服务器110、网络120、乘客终端130、司机终端140和数据库150中的一种或多种。

在一些实施例中，服务器110可以包括处理器11。处理器11可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器11可以基于从乘客终端130获得的服务请求来确定目标车辆。在一些实施例中，处理器11可以包括一个或多个处理核(例如，单核处理器(S)或多核处理器(S))。仅作为举例，处理器11可以包括中央处理单元(Central Processing Unit，CPU)、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、专用指令集处理器(Application Specific Instruction-set Processor，ASIP)、图形处理单元(Graphics Processing Unit，GPU)、物理处理单元(Physics Processing Unit，PPU)、数字信号处理器(Digital Signal Processor，DSP)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、可编程逻辑器件(Programmable Logic Device，PLD)、控制器、微控制器单元、简化指令集计算机(ReducedInstruction Set Computing,RISC)、或微处理器等，或其任意组合。

在一些实施例中，乘客终端130和司机终端140对应的设备类型可以是移动设备，比如可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，也可以是平板计算机、膝上型计算机、或机动车辆中的内置设备等。

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

乘客在需要网约车服务时，通过乘客终端130选择上车地点、下车地点、乘坐人数、出发时间等，以生成一个预订单，预订单中可以显示该行程的预估费用、当前时间点的排队人数以及预估等待时间，当乘客确认无误后，即可发布该预订单，等待订单被响应。

由于在早晚高峰期、下雨等时段，对于网约车的需求量较大，此时呼叫网约车的订单较多，但可用于为乘客服务的车辆的数量远远不够，从而导致出现供需失衡的情况，这将大大减慢订单的响应速度。为了解决这一技术问题，发明人在研究中发现，基于网约车的排队情况为用户推荐能够快速响应的车型，可以大大减少订单的响应时间，提升用户体验。

下面结合上述图1示出的网约车服务系统100中描述的内容，对本申请实施例提供的网约车车型推荐方法进行详细说明。

请参照图2，图2为本申请实施例提供的网约车车型推荐方法的流程图之一。在本实施例中，网约车车型推荐方法应用于网约车服务系统100中的服务器110，所述方法包括：

步骤S101，获取待响应用户选择的上车地点及服务请求时间。

步骤S102，获取在服务请求时间之前，在上车地点的预设距离范围内的排队订单的数量。

步骤S103，根据排队订单的数量、上车地点及服务请求时间生成预订单。

步骤S104，根据排队订单的数量在待响应用户的预订单中推荐目标车型。

在上述步骤中，待响应用户为需要网约车服务的乘客，乘客可以在乘客终端130上选择上车地点、下车地点、出发时间以及乘坐人数等信息，选择完成后即可生成预订单信息。

示例性地，服务器110与乘客终端130通信连接，用于获取待响应用户的选择结果(即上车地点、下车地点、出发时间以及乘坐人数等信息)，在获取到选择结果后，服务器110基于该选择结果获取在服务请求时间之前，且在上车地点的预设距离范围内的排队订单的数量，并基于排队订单的数量生成预订单，同时，服务器110根据排队订单的数量在待响应用户的预订单中推荐目标车型，使得待响应用户的预订单发布后，可以被不同的车型响应，从而加快待响应用户的订单的响应速度，提升用户体验。

示例性地，在本实施例中，根据排队订单的数量在待响应用户的预订单中推荐目标车型包括在乘客终端130的预订单页面上显示服务器110推荐的目标车型，服务器110在分析出推荐的目标车型后，还可以将推荐车型默认勾选。除此之外，预订单页面还可以显示上车地点、下车地点、出发时间、乘坐人数等信息，以及服务器110返回的目前的排队订单的数量和当前行程的预估费用。

可选地，在本实施例中，网约车的车型包括：特快、快车、拼车、专车、出租车、豪华车、优享、商务车等类型。其中，特快车型是一种能够快速响应用户订单的车型。

例如，乘客在打开网约车应用程序之后，可以在页面上选择或者输入上车地点(A地点)、下车地点(B地点)、出发时间(立刻出发)等信息，服务器110在接收到用户的选择结果后，获取在服务请求时间(即当前时刻)之前，在A地点的预设距离范围内(例如3km范围内)的排队订单的数量，并生成预订单。如图3所示，图3为本申请实施例提供的预订单页面示意图。在图3中，预订单中包括有乘客的上车地点(A地点)、下车地点(B地点)、出发时间(现在出发)以及排队订单的数量(例如10人)、预估费用(例如15元)等信息，图3所示的预订单页面还可以显示有服务器110为该预订单推荐的目标车型(例如默认勾选的特快车型、拼车车型、快车车型以及专车车型等)。

基于预订单页面显示的信息，待响应用户可以根据自己的需要取消推荐的目标车型的勾选或是保持不变，并确认预订单中的其他信息是否正确，当待响应用户确认预订单页面的信息准确无误后，可以点击预订单页面上的确认呼叫按键，向服务器110发送该订单，服务器110接收到订单后，根据订单信息为该用户分配车辆，从而为该用户提供网约车服务。

在本实施例中，排队订单的数量的多少会对推荐的目标车型的种类造成影响。示例性地，请参照图4，图4为本申请实施例提供的步骤S104的子步骤流程图。在本实施例中，步骤S104包括：

子步骤S1041，判断排队订单的数量是否大于第一预设值。

排队订单的数量是指在待响应用户的服务请求时间之前，且在待响应用户的上车地点的预设距离范围内已经确认呼叫的订单数量。

例如，待响应用户的服务器110请求时间为立刻出发，上车地点为A地点，则服务器110获取在当前时刻之前，上车地点在A地点的预设距离范围内(例如3km)的其他用户的订单数量，例如，可以为15单，即表示，在待响应用户的上车地点周围，已经有15个订单需要分配网约车。

设置预设距离范围是因为相隔距离较远的两个上车地点寻找车辆的范围是不同的，例如，A地点若与B地点相隔10公里，则为A地点对应的订单分配的车辆与为B地点对应的订单分配的车辆是位于不同区域范围内的车辆，可以同时分配，无需排队。

在一些实施方式中，第一预设值可以灵活设置，如设置为10或20，相应地，首先需要判断待响应用户前面等待响应的订单数量(排队订单的数量)是否大于10或20。

值得说明的是，在本实施例的其他实施方式中，预设距离范围及第一预设值的大小还可以为其他数值，在此不作具体限定。

子步骤S1042，若排队订单的数量大于第一预设值，则从待响应用户的历史订单中获取第一目标订单及第二目标订单。其中，第一目标订单为最近一次发布且在发布时排队订单的数量大于第一预设值的历史订单，第二目标订单为所述待响应用户最近一次发布的历史订单。

子步骤S1043，根据待响应用户在发布第一目标订单和第二目标订单时选择的车型在该待响应用户的预订单中推荐相应的目标车型。

在上述子步骤中，当排队订单的数量大于第一预设值时，则表示此时的排队现象较为严重，为了加快对待响应用户的订单的响应速度，可以给用户推荐目标车型。

示例性地，先从待响应用户的历史订单中获取第一目标订单及第二目标订单，并根据待响应用户在发布第一目标订单和第二目标订单时选择的车型为该待响应用户推荐目标车型。

可选地，在本实施例中，第一目标订单和第二目标订单可以为同一订单也可以为不同订单。

例如，乘客张三的预订单信息中，本次网约车服务还需要排队30人，已经大于了第一预设值(例如20)，则服务器110从张三的历史订单中查找第一目标订单X和第二目标订单Y。其中，第一目标订单X是指张三在最近一次呼叫网约车且排队订单数量大于20的历史订单；第二目标订单Y则是指张三的上一个订单。

当第一目标订单X和第二目标订单Y为不同的订单时，假如张三在发布的第一目标订单X中选择了特快车型及拼车车型，张三在发布的第二目标订单Y中选择了快车车型和拼车车型，则为乘客张三的本次预订单推荐的目标车型为快车车型、拼车车型和特快车型，在乘客张三的预订单页面上显示或默认勾选快车车型、拼车车型和特快车型，其余车型被折叠显示在预订单页面中。

当第一目标订单X和第二目标订单Y为同一个订单时，即乘客张三的上一个订单排队订单的数量大于20。将乘客张三在上一个订单中选择的车型作为目标车型推荐给该用户，在预订单页面中显示或默认勾选目标车型，其余未推荐的车型可以折叠显示在预订单页面中。

若乘客张三在最近一次需要排队等待的订单数量大于20时，没有选择特快车型或拼车车型，则本次预订单中不会推荐特快车型或拼车车型。

另外，目标车型仅为服务器110根据待响应用户的使用习惯及排队情况推荐的一部分车型，并不代表用户只能选择推荐的目标车型，待响应用户也可以根据自己的需求自主选择需要乘坐的车型。

在上述实施例中，通过将待响应用户在第一目标订单和第二目标订单中选择的车型作为该用户推荐的目标车型，在提高响应效率的同时，可以使得推荐的目标车型更贴合该用户的使用习惯，避免为用户推荐不常用的车型。另外，还可以根据用户在上一次需要排队时的订单中是否勾选特快车型，判断出该用户是否想要被快速响应，使得推荐的目标车型与该用户更加契合，从而提升用户体验。

请继续参照图4，在本实施例中，若排队订单的数量不大于第一预设值，网约车车型推荐方法还包括：

子步骤S1044，从待响应用户的历史订单中获取第二目标订单。

子步骤S1045，根据待响应用户在发布第二目标订单时选择的车型在该待响应用户的预订单中推荐相应的目标车型。

在上述子步骤中，排队订单的数量也有可能大于0但是不大于第一预设值(例如不大于20单)，可以理解为此时呼叫网约车需要排队，但前方等待响应的其他用户的订单的数量较少，等待时间较短，此时可以直接从待响应用户的历史订单中获取第二目标订单，无需获取第一目标订单。最终将待响应用户在第二目标订单中选择的车型作为该用户推荐的目标车型。

例如，若乘客李四的预订单中，排队订单的数量为5个，未超过第一预设值(20个)，则表示当前时刻的订单请求与车辆数量的差异不大，用户无需等待很长时间，则服务器110直接获取乘客李四的历史订单中的上一个订单(即第二目标订单)。

若乘客李四在上一个订单中选择的车型为特快车型及拼车车型，则服务器110在该乘客本次的预订单页面中推荐的目标车型为特快车型及拼车车型。乘客在确认预订单信息无误后，点击确认呼叫，生成服务请求订单发送至服务器110，服务器110接收到服务请求订单后，为该乘客分配车辆。

可选地，服务器110通常可以为乘客推荐多个目标车型，当根据待响应用户在历史订单中选择的车型所推荐的目标车型的种类较少时，例如，乘客的历史订单中的每一个订单都只选择了一个车型，最终推荐的目标车型的也只有一个，此时需要对目标车型进行数量补齐。

示例性地，请参照图5，图5为本申请实施例提供的网约车车型推荐方法的流程图之二。在本实施例中，所述方法还包括：

步骤S105，判断推荐的目标车型的数量是否达到第二预设值。

步骤S106，若未达到所述第二预设值，则将目标车型的数量补齐至第二预设值。

在一种实施方式中，例如，若待响应用户在第一目标订单及第二目标订单中选择的车型为特快车型、拼车车型及快车车型，则服务器110为该待响应用户当前的预订单推荐的车型也为特快车型、拼车车型及快车车型。

当第二预设值为4时，即预订单页面中可以显示的目标车型的数量为4，在上述例子中，由于推荐的目标车型的数量只有3个，小于4，因此，需要将推荐的目标车型的数量补齐至4个。

当然，在本实施例的其他实施方式中个，服务器110推荐的目标车型的数量也可以为其他数值，或是第二预设值为其他数值，在此不作具体限定。

示例性地，请参照图6，图6为本申请实施例提供的步骤S106的子步骤流程图之一。在本实施例中，步骤S106包括：

子步骤S1061，计算待响应用户在预设时间范围内的历史订单中选择的车型的次数。

子步骤S1062，按照各车型被选择的次数从多到少的顺序，进行目标车型添加，直至目标车型的数量达到第二预设值。

在实施过程中，服务器110从数据库150中获取待响应用户在预设时间范围内(例如一个月内或一周内)的历史订单，并计算待响应用户在此时间段内的历史订单中选择各车型的次数，根据被选择次数从多到少的顺序，进行目标车型的添加，直到目标车型的数量达到第二预设值。

例如，乘客在一个月内的历史订单数量为20单，若该乘客在此20个历史订单中，选择快车车型的次数为20次，选择特快车型的数量为15次，选择专车车型的次数为10次，选择拼车车型的次数为5次，选择豪华车车型的次数为2次。

按照各个车型被选择的次数从多到少的顺序进行目标车型添加，直至目标车型的数量达到第二预设值。在上述例子中，应当按照快车、特快、专车、拼车以及豪华车的顺序，依次进行目标车型的添加。

在本实施例的一些实施方式中，若存在两种车型被选择的次数相同，可以根据其他用户对这两种车型的接受度进行排序，先将接受度高的车型添加至目标车型中。

示例性地，在本实施例中，子步骤S1062，按照各车型被选择的次数从多到少的顺序，进行目标车型添加，直至目标车型的数量达到第二预设值，可以包括：

按照各车型中不是目标车型的备用推荐车型被选择的次数从多到少的顺序，将备用推荐车型依次添加为目标车型。

在实施过程中，若服务器110为待响应用户推荐的车型包括特快车型及拼车车型，此时的目标车型数量为2，小于第二预设值(例如4)，则需要计算待响应用户的历史订单中除了目标车型外的备用推荐车型被选择的次数，即除了特快车型及拼车车型之外的其他车型(可以是豪华车车型、专车车型或商务车车型等)被选择的次数，并按照次数从多到少的顺序，将备用推荐车型添加为目标车型，直至目标车型的数量达到第二预设值。

在一些实施例中，在待响应用户的所有历史订单中被选择的车型的种类也有可能只有特快车型和拼车车型，这两种车型和推荐的目标车型相同，即不存在备用推荐车型，此时可以根据除了特快车型和拼车车型之外的其他车型的大众接受度的高低顺序，进行目标车型的添加，直至目标车型的数量达到第二预设值。

在本实施例的另一实施方式中，请参照图7，图7为本申请实施例提供的步骤S106的子步骤流程图之二。在本实施方式中，步骤S106可以包括：

子步骤S1063，计算在服务请求时间的预设时间范围内且在上车地点的预设距离范围内的其他用户的订单信息中，各个车型被选择的次数。

子步骤S1064，按照各车型被选择的次数从多到少的顺序，进行目标车型添加，直至目标车型的数量达到第二预设值。

在实施过程中，在进行目标车型补齐时，服务器110还可以获取在待响应用户的服务请求时间的预设时间范围内，且在上车地点的预设距离范围内的订单，例如，若乘客的服务请求时间为当前时刻，上车地点为A地点，则服务器110获取在当前时刻之前的一段时间(例如15分钟)内，且在A地点附近(例如距离A地点3km的范围内)的其他用户的订单信息，计算在其他用户的订单信息中各车型被选择的次数，按照次数从多到少的顺序添加目标车型，直至目标车型的数量达到第二预设值。

例如，假设在当前时刻的15分钟内，上车地点为距离A地点3km的范围内的其他用户的订单数量为50单，若在此50个订单信息中，选择快车车型的次数为40次，选择特快车型的数量为30次，选择专车车型的次数为15次，选择拼车车型的次数为35次，选择豪华车车型的次数为10次。

按照各个车型被选择的次数从多到少的顺序进行目标车型添加，直至目标车型的数量达到第二预设值。在上述例子中，应当按照快车、拼车、特快、专车以及豪华车的顺序，依次进行目标车型的添加。

在本实施例的一些实施方式中，若存在两种车型被选择的次数相同，可以根据这两种车型的大众接受度进行排序，按照大众接受度高低，先将接受度高的车型添加至目标车型中。

示例性地，在本实施方式中，子步骤S1062，按照各车型被选择的次数从多到少的顺序，进行目标车型添加，直至目标车型的数量达到第二预设值，可以包括：

按照各车型中不是目标车型的备用推荐车型被选择的次数从多到少的顺序，将备用推荐车型依次添加为目标车型。

在实施过程中，若服务器110为待响应用户推荐的车型包括特快车型、拼车车型及快车车型，此时的目标车型数量为3，小于第二预设值(例如4)，则需要计算在服务请求时间的预设时间范围内(例如15分钟内)，在上车地点为A地点的预设距离范围内(例如3km范围内)的其他用户的订单信息中除了目标车型外的备用推荐车型被选择的次数，即除了特快车型、拼车车型及快车车型之外的其他车型(可以是豪华车车型、专车车型或商务车车型等其他车型)被选择的次数，并按照次数从多到少的顺序，将备用推荐车型添加为目标车型，直至目标车型的数量达到第二预设值。

在一些实施例中，在服务请求时间的预设时间范围内(例如15分钟内)，在上车地点为A地点的预设距离范围内(例如3km范围内)的其他用户的订单信息中被选择的车型也有可能只有特快车型、拼车车型及快车车型，这三种车型和推荐的目标车型相同，即不存在备用推荐车型，此时可以根据除了特快车型、拼车车型及快车车型之外的其他车型的大众接受度的高低顺序，进行目标车型的添加，直至目标车型的数量达到第二预设值。

综上所述，本申请实施例提供了一种网约车车型推荐方法，通过获取待响应用户选择的上车地点及服务请求时间，获取在服务请求时间之前，且在上车地点的预设距离范围内的排队订单的数量，根据排队订单的数量在待响应用户的预订单中推荐目标车型，从而使得待响应用户的预订单发布后，可以被目标车型响应，从而加快待响应用户的订单的响应速度，提升用户体验。

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

请参照图8，图8为本申请实施例提供的网约车车型推荐装置200的功能模块图，所述装置包括：第一获取模块210、第二获取模块220、预订单生成模块230以及车型推荐模块240。

其中，第一获取模块210，用于获取待响应用户选择的上车地点及服务请求时间；

第二获取模块220，用于获取在所述服务请求时间之前，在所述上车地点的预设距离范围内的排队订单的数量；

预订单生成模块230，用于根据所述排队订单的数量、上车地点及所述服务请求时间生成预订单；

车型推荐模块240，用于根据所述排队订单的数量在所述待响应用户的预订单中推荐目标车型。

本申请实施例通过获取待响应用户选择的上车地点及服务请求时间，获取在服务请求时间之前，且在上车地点的预设距离范围内的排队订单的数量，根据排队订单的数量在待响应用户的预订单中推荐目标车型，从而使得待响应用户的预订单发布后，可以被目标车型响应，从而加快待响应用户的订单的响应速度，提升用户体验。

可选地，在本实施例中，车型推荐模块240包括：

判断子模块，用于判断所述排队订单的数量是否大于第一预设值；

第一历史订单获取子模块，用于在所述排队订单的数量大于所述第一预设值时，从所述待响应用户的历史订单中获取第一目标订单及第二目标订单。其中，所述第一目标订单为最近一次发布且在发布时排队订单的数量大于所述第一预设值的历史订单，所述第二目标订单为所述待响应用户最近一次发布的历史订单；

第一目标车型推荐子模块，用于根据所述待响应用户在发布所述第一目标订单和所述第二目标订单时选择的车型在该待响应用户的所述预订单中推荐相应的目标车型。

可选地，在本实施例中，所述车型推荐模块240还包括：

第二历史订单获取子模块，用于在所述排队订单的数量不大于所述第一预设值时，从所述待响应用户的历史订单中获取所述第二目标订单；

第二目标车型推荐子模块，用于根据所述待响应用户在发布所述第二目标订单时选择的车型在该待响应用户的所述预订单中推荐相应的目标车型。

可选地，在本实施例中，所述网约车车型推荐装置200还包括：

数量判断模块250，用于判断推荐的目标车型的数量是否达到第二预设值；

车型补齐模块260，用于在未达到第二预设值时，将所述目标车型的数量补齐至第二预设值。

可选地，在本实施例中，车型补齐模块260，具体用于：

计算所述待响应用户在预设时间范围内的历史订单中选择的车型的次数；按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，直至所述目标车型的数量达到第二预设值。

可选地，在本实施例中，车型补齐模块260用于通过以下步骤按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，直至所述目标车型的数量达到第二预设值：

按照各车型中不是目标车型的备用推荐车型被选择的次数从多到少的顺序，将备用推荐车型依次添加为目标车型。

可选地，在本实施例的其他实施方式中，车型补齐模块260，具体用于：

计算在所述服务请求时间的预设时间范围内且在所述上车地点的预设距离范围内的其他用户的订单信息中，各个车型被选择的次数；

按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，直至所述目标车型的数量达到第二预设值。

具体地，车型补齐模块260用于通过以下步骤按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加：

按照各所述车型中不是目标车型的备用推荐车型被选择的次数从多到少的顺序，将所述备用推荐车型依次添加为目标车型。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

请结合参阅图9，本申请实施例还提供了一种电子设备10，在本实施中，电子设备10可以理解为前述步骤中的服务器110，用于实施前述实施例提供的网约车车型推荐方法的步骤。

如图9所示，为本申请实施例提供的电子设备10结构示意图，包括：处理器11、存储器12、和总线13。所述存储器12存储有所述处理器11可执行的机器可读指令(比如，图8中的网约车车型推荐装置200中第一获取模块210、第二获取模块220、预订单生成模块230以及车型推荐模块240对应的执行指令等)，当电子设备10运行时，所述处理器11与所述存储器12之间通过总线13通信，所述机器可读指令被所述处理器11执行时执行上述实施例提供的网约车车型推荐方法的步骤。

本申请实施例还提供了一种存储介质，该存储介质上存储有计算机程序，该计算机程序被处理器11运行时执行上述网约车车型推荐方法的步骤。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的计算机程序被运行时，能够执行上述网约车车型推荐方法，从而使得待响应用户的预订单发布后，可以被不同的车型响应，加快待响应用户的订单的响应速度，提升用户体验。

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

另外，在本申请各个实施例中的各功能单元可以集成在一为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。

应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

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

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

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

Claims (10)

1.一种网约车车型推荐方法，其特征在于，包括：

获取待响应用户选择的上车地点及服务请求时间；

获取在所述服务请求时间之前，在所述上车地点的预设距离范围内的排队订单的数量；

根据所述排队订单的数量、上车地点及所述服务请求时间生成预订单；

根据所述排队订单的数量在所述待响应用户的预订单中推荐目标车型。

2.根据权利要求1所述的方法，其特征在于，所述根据所述排队订单的数量在所述待响应用户的预订单中推荐目标车型，包括：

判断所述排队订单的数量是否大于第一预设值；

若所述排队订单的数量大于所述第一预设值，则从所述待响应用户的历史订单中获取第一目标订单及第二目标订单，其中，所述第一目标订单为最近一次发布且在发布时排队订单的数量大于所述第一预设值的历史订单，所述第二目标订单为所述待响应用户最近一次发布的历史订单；

根据所述待响应用户在发布所述第一目标订单和所述第二目标订单时选择的车型在该待响应用户的所述预订单中推荐相应的目标车型。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

若所述排队订单的数量不大于所述第一预设值，则从所述待响应用户的历史订单中获取所述第二目标订单；

根据所述待响应用户在发布所述第二目标订单时选择的车型在该待响应用户的所述预订单中推荐相应的目标车型。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

判断推荐的目标车型的数量是否达到第二预设值；

若未达到所述第二预设值，则将所述目标车型的数量补齐至所述第二预设值。

5.根据权利要求4所述的方法，其特征在于，所述将所述目标车型的数量补齐至所述第二预设值，包括：

计算所述待响应用户在预设时间范围内的历史订单中选择的车型的次数；

按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，直至所述目标车型的数量达到第二预设值。

6.根据权利要求4所述的方法，其特征在于，所述将所述目标车型的数量补齐至所述第二预设值，包括：

计算在所述服务请求时间的预设时间范围内且在所述上车地点的预设距离范围内的其他用户的订单信息中，各个车型被选择的次数；

按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，直至所述目标车型的数量达到第二预设值。

7.根据权利要求5或6所述的方法，其特征在于，按照各所述车型被选择的次数从多到少的顺序，进行目标车型添加，包括：

按照各所述车型中不是目标车型的备用推荐车型被选择的次数从多到少的顺序，将所述备用推荐车型依次添加为目标车型。

8.一种网约车车型推荐装置，其特征在于，包括：

第一获取模块，用于获取待响应用户选择的上车地点及服务请求时间；

第二获取模块，用于获取在所述服务请求时间之前，在所述上车地点的预设距离范围内的排队订单的数量；

预订单生成模块，用于根据所述排队订单的数量、上车地点及所述服务请求时间生成预订单；

车型推荐模块，用于根据所述排队订单的数量在所述待响应用户的预订单中推荐目标车型。

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

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

Images