一种服务推送方法、装置、电子设备以及存储介质与流程

1.本申请涉及计算机技术领域，具体而言，涉及一种服务推送方法、装置、电子设备以及存储介质。


背景技术：

2.网约车平台作为沟通乘客终端和司机终端的平台，乘客终端通过在网约平台上发送打车请求，进而网约平台根据打车请求生成订单，以发送司机终端，实现司机终端接收乘客终端发送的订单。
3.为了更好的服务乘客，网约平台为乘客提供了多种出行方式，比如：出租车、专车、快车、顺风车等出行方式。网约平台一般会通过对服务请求端的分析，来采取多种策略将乘客或者司机挽留在网约平台以促进服务请求端增长。但现有的服务请求端分析多采用点状分析和经验复用的方式，缺乏基于服务请求端个体维度的分析和运营，忽略了服务请求端的个性化需求。


技术实现要素：

4.有鉴于此，本申请的目的在于提供一种服务推送方法、装置、电子设备以及存储介质，能够针对用户的异质性需求提供有针对性的出行服务。
5.根据本申请的一个方面，提供一种服务推送方法，包括：
6.获取服务请求端当前的出行场景信息；
7.根据所述出行场景信息，确定服务请求端当前所在的目标出行场景；
8.查找所述目标出行场景的类型所对应的目标出行服务；在所述目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级；所述推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的；
9.向服务请求端推荐所述目标出行服务。
10.在一些实施例中，获取服务请求端当前的出行场景信息，可包括：基于服务请求端所发出的出行订单操作请求，获取服务请求端当前的出行场景信息；所述出行订单操作请求包括以下至少一项：出行订单下达请求、出行订单的地点输入请求、出行订单的服务类型选择请求、出行订单预备请求。
11.在一些实施例中，所述出行场景信息可包括以下至少一项：服务请求端当前所处的场所类型、服务请求端当前所处的下单阶段、服务请求端当前所在地的天气数据。
12.在一些实施例中，可通过以下方式确定所述目标出行场景：分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量；针对每个类型的出行服务，根据该出行服务的供给饱和度和订单执行量计算该出行服务的推荐优先级；根据不同出行服务的推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
13.在一些实施例中，可通过以下方式确定所述目标出行场景：分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量；根据每个类型的出行服务的供给
饱和度和订单执行量，分别形成关于供给饱和度的排名和关于订单执行量的排名；针对每个类型的出行服务，根据该出行服务关于供给饱和度的排名和关于订单执行量的排名，确定该出行服务的推荐优先级；根据不同出行服务的推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
14.在一些实施例中，所述订单执行量可包括以下至少一项：用车呼叫量、用车去重呼叫量、订单数量、订单资源、完单数量。
15.在一些实施例中，推荐优先级与供给饱和度呈负相关性；推荐优先级与订单执行量呈负相关性。
16.在一些实施例中，所述服务推送方法可还包括：根据不同服务请求端使用出行服务的出行订单数据所确定的用户留存时间和服务请求端在不同时间的出行订单数据，确定服务请求端当前所处的服务阶段；不同的服务阶段对应的服务偏好是不同的；其中，查找所述目标出行场景的类型所对应的目标出行服务，可包括：分别获取目标出行场景中，每个类型的出行服务与服务请求端当前所处的服务阶段对应的服务偏好的匹配度；根据不同出行服务的匹配度和推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
17.在一些实施例中，服务请求端在不同时间的出行订单数据，可包括服务请求端在不同时间使用出行服务的订单数量，其中，可通过以下方式确定用户留存时间：根据不同服务请求端使用出行服务的订单数量，计算关于服务请求端在不同时间的订单数量的拐点；根据拐点所对应的时间，确定用户留存时间。
18.在一些实施例中，根据不同服务请求端使用出行服务的出行订单数据所确定的用户留存时间和服务请求端在不同时间的出行订单数据，确定服务请求端当前所处的服务阶段，可包括：获取预定时间段内的服务请求端使用出行服务所下达的订单数量；所述预定时间段基于用户留存时间来确定；基于所提取的订单数量与不同服务阶段对应的匹配条件的匹配结果，确定服务请求端当前所处的服务阶段。
19.在一些实施例中，所述服务推送方法可还包括：响应于所述服务请求端下达的针对推荐的目标出行服务的下单请求，生成出行订单；将所述出行订单分配给服务提供方，并在将所述出行订单分配给服务提供方之后，在服务提供方接乘到持有所述服务请求端的服务请求方之前，向所述服务请求端发送用于促使所述出行订单完成的交互信息。
20.在一些实施例中，所述服务推送方法可还包括：根据不同服务请求端使用出行服务的出行订单数据所确定的用户留存时间和服务请求端的出行订单数据，确定服务请求端所属的用户类型；不同的用户类型对应的服务请求端使用出行服务的频次不同；其中，查找所述目标出行场景的类型所对应的目标出行服务，包括：分别获取目标出行场景中，每个类型的出行服务与服务请求端所属的用户类型的匹配度；根据不同出行服务的匹配度和推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
21.在一些实施例中，根据不同服务请求端使用出行服务的出行订单数据所确定的用户留存时间和服务请求端的出行订单数据，确定服务请求端所属的用户类型，可包括：基于用户留存时间，从所述服务请求端的出行订单数据中提取服务请求端的出行特征信息；将所提取的服务请求端的出行特征信息输入到用户分类模型，以获得服务请求端所属的用户类型；其中，所述服务请求端的出行特征信息可包括：服务请求端的最近完单距当前时间的
时长、位于当前时间之前且相邻的用户留存时间内的完单频次、位于当前时间之前且相邻的用户留存时间内的完单金额、历史完单量。
22.根据本申请的另一个方面，提供一种服务推送方法，包括：
23.获取服务请求端当前的出行场景信息；
24.根据所述出行场景信息，确定服务请求端当前所在的目标出行场景；
25.查找所述目标出行场景的类型所对应的目标出行服务；在所述目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级；所述推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的；
26.在图形用户界面上展示推荐使用所述目标出行服务的提示信息。
27.在一些实施例中，获取服务请求端当前的出行场景信息，可包括：响应于服务请求端接收用户输入的触控操作，确定当前是否处于预定的订单下达阶段；若当前处于预定的订单下达阶段，则获取服务请求端与预定的订单下达阶段对应的当前的出行场景信息；所述预定的订单下达阶段可包括以下至少一项：出行订单下达阶段、出行订单的地点输入阶段、出行订单的服务类型选择阶段。
28.根据本申请的另一个方面，提供一种服务推送装置，包括：
29.场景信息获取模块，获取服务请求端当前的出行场景信息；
30.出行场景确定模块，根据所述出行场景信息，确定服务请求端当前所在的目标出行场景；
31.出行服务确定模块，查找所述目标出行场景的类型所对应的目标出行服务；在所述目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级；所述推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的；
32.出行服务推荐模块，向服务请求端推荐所述目标出行服务。
33.在一些实施例中，场景信息获取模块可基于服务请求端所发出的出行订单操作请求，获取服务请求端当前的出行场景信息；所述出行订单操作请求可包括以下至少一项：出行订单下达请求、出行订单的地点输入请求、出行订单的服务类型选择请求。
34.在一些实施例中，所述出行场景信息可包括以下至少一项：服务请求端当前所处的场所类型、服务请求端当前所处的下单阶段、服务请求端当前所在地的天气数据。
35.在一些实施例中，出行场景确定模块可通过以下方式确定所述目标出行场景：分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量；针对每个类型的出行服务，根据该出行服务的供给饱和度和订单执行量计算该出行服务的推荐优先级；根据不同出行服务的推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
36.在一些实施例中，出行场景确定模块可通过以下方式确定所述目标出行场景：分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量；根据每个类型的出行服务的供给饱和度和订单执行量，分别形成关于供给饱和度的排名和关于订单执行量的排名；针对每个类型的出行服务，根据该出行服务关于供给饱和度的排名和关于订单执行量的排名，确定该出行服务的推荐优先级；根据不同出行服务的推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
37.在一些实施例中，所述订单执行量可包括以下至少一项：用车呼叫量、用车去重呼
叫量、订单数量、订单资源、完单数量。
38.在一些实施例中，推荐优先级与供给饱和度呈负相关性；推荐优先级与订单执行量呈负相关性。
39.在一些实施例中，可还包括：服务阶段确定模块，根据不同服务请求端使用出行服务的出行订单数据所确定的用户留存时间和服务请求端在不同时间的出行订单数据，确定服务请求端当前所处的服务阶段；不同的服务阶段对应的服务偏好是不同的；其中，出行服务确定模块分别获取目标出行场景中，每个类型的出行服务与服务请求端当前所处的服务阶段对应的服务偏好的匹配度；根据不同出行服务的匹配度和推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
40.在一些实施例中，服务请求端在不同时间的出行订单数据，包括服务请求端在不同时间使用出行服务的订单数量，其中，服务阶段确定模块可通过以下方式确定用户留存时间：根据不同服务请求端使用出行服务的订单数量，计算关于服务请求端在不同时间的订单数量的拐点；根据拐点所对应的时间，确定用户留存时间。
41.在一些实施例中，服务阶段确定模块获取预定时间段内的服务请求端使用出行服务所下达的订单数量；所述预定时间段基于用户留存时间来确定；基于所获取的订单数量与不同服务阶段对应的匹配条件的匹配结果，确定服务请求端当前所处的服务阶段。
42.在一些实施例中，出行服务推荐模块可响应于所述服务请求端下达的针对推荐的目标出行服务的下单请求，生成出行订单；将所述出行订单分配给服务提供方，并在将所述出行订单分配给服务提供方之后，在服务提供方接乘到持有所述服务请求端的服务请求方之前，向所述服务请求端发送用于促使所述出行订单完成的交互信息。
43.在一些实施例中，还包括：用户类型确定模块，根据不同服务请求端使用出行服务的出行订单数据所确定的用户留存时间和服务请求端的出行订单数据，确定服务请求端所属的用户类型；不同的用户类型对应的服务请求端使用出行服务的频次不同；其中，出行服务确定模块分别获取目标出行场景中，每个类型的出行服务与服务请求端所属的用户类型的匹配度；根据不同出行服务的匹配度和推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。
44.在一些实施例中，用户类型确定模块基于用户留存时间，从所述服务请求端的出行订单数据中提取服务请求端的出行特征信息；将所提取的服务请求端的出行特征信息输入到用户分类模型，以获得服务请求端所属的用户类型；其中，所述服务请求端的出行特征信息可包括：服务请求端的最近完单距当前时间的时长、位于当前时间之前且相邻的用户留存时间内的完单频次、位于当前时间之前且相邻的用户留存时间内的完单金额、历史完单量。
45.根据本申请的另一方面，还提供一种电子设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储器之间通过总线通信，所述处理器执行所述机器可读指令，以执行上述的服务推送方法的步骤。
46.根据本申请的另一方面，提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述的服务推送方法的步骤。
47.根据本申请的另一方面，提供一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现上述的服务推送方法的步骤。
48.本申请实施例提供的服务推送方法：获取服务请求端当前的出行场景信息；根据所述出行场景信息，确定服务请求端当前所在的目标出行场景；查找所述目标出行场景的类型所对应的目标出行服务；在所述目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级；所述推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的；向服务请求端推荐所述目标出行服务。
49.与现有技术相比，通过针对服务请求端所处的目标出行场景进行目标出行服务推送，使得向服务请求端推送的出行服务更具有针对性、精确性。
50.为使本申请的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。
附图说明
51.为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
52.图1示出了本申请实施例所提供的一种服务推送系统的结构示意图；
53.图2示出了本申请实施例所提供的一种服务推送方法的流程图；
54.图3示出了本申请实施例所提供的存在返程需求的出行场景的示例；
55.图4示出了本申请实施例所提供的查找目标出行场景的类型所对应的目标出行服务的一种方式的流程图；
56.图5示出了本申请实施例所提供的查找目标出行场景的类型所对应的目标出行服务的另一种方式的流程图；
57.图6示出了本申请实施例所提供的另一种服务推送方法的流程图；
58.图7示出了本申请实施例所提供的确定用户留存时间的示例图；
59.图8示出了本申请实施例所提供的多个服务阶段的示例图；
60.图9示出了本申请实施例所提供的再一种服务推送方法的流程图；
61.图10示出了本申请实施例所提供的确定在出行订单全流程中用于触发推送交互信息的关键环节的示例图；
62.图11示出了本申请实施例所提供的再一种服务推送方法的流程图；
63.图12示出了本申请实施例所提供的一种服务推送装置的结构示意图；
64.图13示出了本申请实施例所提供的另一种服务推送装置的结构示意图；
65.图14示出了本申请实施例所提供的一种电子设备的结构示意图。
具体实施方式
66.为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实
施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的每个其他实施例，都属于本申请保护的范围。
67.为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“网约车”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕网约车进行描述，但是应该理解，这仅是一个示例性实施例。
68.需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。
69.本申请中的术语“乘客”、“请求方”、“服务请求方”和“客户”可互换使用，以指代可以请求或订购服务的个人、实体或工具。本申请中的术语“司机”、“提供方”、“服务提供方”和“供应商”可互换使用，以指代可以提供服务的个人、实体或工具。本申请中的术语“用户”可以指代请求服务、订购服务、提供服务或促成服务的提供的个人、实体或工具。例如，用户可以是乘客、驾驶员、操作员等，或其任意组合。在本申请中，“乘客”和“乘客终端”可以互换使用，“驾驶员”和“驾驶员终端”可以互换使用。
70.本申请中的术语“服务请求”和“订单”可互换使用，以指代由乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合发起的请求。接受该“服务请求”或“订单”的可以是乘客、服务请求方、司机、服务提供方、或供应商等、或其任意组合。服务请求可以是收费的或免费的。
71.本申请中使用的定位技术可以基于全球定位系统(global positioning system,gps)、全球导航卫星系统(global navigation satellite system,glonass)，罗盘导航系统(compass)、伽利略定位系统、准天顶卫星系统(quasi
‑
zenith satellite system,qzss)、无线保真(wireless fidelity,wifi)定位技术等，或其任意组合。一个或多个上述定位系统可以在本申请中互换使用。
72.本申请的一个方面涉及一种服务推送系统。该系统可以实现服务器、服务请求端、服务提供端之间的交互，并针对服务请求端的目标出行场景的类型提供对应的目标出行服务，以满足服务请求端的个性化需求。
73.值得注意的是，在本申请提出申请之前，现有的出行服务是针对某个用户群体来进行推送。或者是采用经验复用的方式，将其他出行方式的分析结果直接应用到目标出行方式上，例如，将针对拼车用户推送的出行服务，直接复用到快车用户上，但是拼车用户与快车用户在构成、人群特点、产品适用周期上都存在天然不同，导致针对用户推送的出行服务不够精确。
74.然而，本申请提供的服务推送系统通过分析服务请求端所处的目标出行场景，来针对目标出行场景进行推送，使得所推送的目标出行服务更为精确。
75.图1是本申请实施例提供的一种服务推送系统100的结构示意图。例如，服务推送系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务推送系统100可以包括服务器110、网络120、服务请求端130、服务提供端140、和数据库150中的一种或多种。
76.在一些实施例中，服务器110可以包括处理器。处理器可以处理与服务请求有关的信息和/或数据，以执行本申请中描述的一个或多个功能。例如，处理器可以基于从服务请求端130获得的服务请求来确定目标车辆。在一些实施例中，处理器可以包括一个或多个处理核(例如，单核处理器(s)或多核处理器(s))。仅作为举例，处理器可以包括中央处理单元(central processing unit,cpu)、专用集成电路(application specific integrated 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)、控制器、微控制器单元、简化指令集计算机(reduced instruction set computing,risc)、或微处理器等，或其任意组合。
77.在一些实施例中，服务请求端130和服务提供端140对应的设备类型可以是移动设备，比如可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等，也可以是平板计算机、膝上型计算机、或机动车辆中的内置设备等。
78.在一些实施例中，数据库150可以连接到网络120以与服务推送系统100中的一个或多个组件(例如，服务器110，服务请求端130，服务提供端140等)通信。服务推送系统100中的一个或多个组件可以经由网络120访问存储在数据库150中的数据或指令。在一些实施例中，数据库150可以直接连接到服务推送系统100中的一个或多个组件，或者，数据库150也可以是服务器110的一部分。
79.下面结合上述图1示出的服务推送系统100中描述的内容，对本申请实施例提供的服务推送方法进行详细说明。
80.参照图2所示，为本申请实施例提供的一种服务推送方法的流程示意图，该方法可以由服务推送系统100中的服务器110来执行，也可以由服务请求端130来执行，具体执行过程为：
81.步骤s101，获取服务请求端当前的出行场景信息。
82.在一实施例中，可以基于服务请求端所发出的出行订单操作请求，获取服务请求端当前的出行场景信息。
83.示例性地，出行订单操作请求可包括但不限于以下的任意一种或多种：出行订单下达请求、出行订单的地点输入请求、出行订单的服务类型选择请求、出行订单预备请求。
84.在一示例中，针对出行订单操作请求为出行订单下达请求的情况，可在服务请求端130显示出行订单的操作界面，当接收到服务请求端对该操作界面中的下单选项(如“呼叫用车”选项)的选择操作时，服务请求端130获取服务请求端当前的出行场景信息，并上传至服务器110，即，此时服务器110从服务请求端130获取服务请求端当前的出行场景信息。
85.在另一示例中，针对出行订单操作请求为出行订单的地点输入请求的情况，可在服务请求端130显示出行订单的操作界面，当接收到服务请求端130在该操作界面中的目的地输入框中输入目的地的地点时，确定为接收到出行订单的地点输入请求，此时服务请求端130获取服务请求端当前的出行场景信息，并上传至服务器110。在上述示例中，也可以是在接收到服务请求端在该操作界面中针对出发地的选择时确定为接收到出行订单的地点输入请求。
86.在另一示例中，针对出行订单操作请求为出行订单的服务类型选择请求的情况，可在服务请求端130显示出行订单的操作界面，当接收到服务请求端对该操作界面中的关于任一服务类型的选项的选择操作(如对“打车”、“拼车”、“顺风车”选项的选择操作)时，服务请求端130获取服务请求端当前的出行场景信息，并上传至服务器110。
87.应理解，上述所列举的关于服务请求端当前的出行场景信息的获取时机的几种方式仅为示例，本申请不限于此，本领域技术人员可以根据需要来调整获取服务请求端当前的出行场景信息的时机。
88.此外，作为示例，出行场景信息可包括但不限于以下的任意一种或多种：服务请求端当前所处的场所类型、服务请求端当前所处的下单阶段、服务请求端当前所在地的天气数据。
89.示例性地，场所类型可包括但不限于以下的任意一种或多种：通勤场所(家或者公司)、交通枢纽场所(如客运站、火车站、飞机场)、休闲娱乐场所(如商场、娱乐场所)、商务场所(如商务宾馆、酒店)。
90.在一示例中，针对出行场景信息为服务请求端当前所处的场所类型的情况，可通过如下方式来获取服务请求端当前的出行场景信息：可以定位服务请求端的当前位置，基于该当前位置确定服务请求端所在地，将服务请求端所在地所属的场所类型确定为服务请求端当前所处的场所类型。
91.在另一示例中，针对出行场景信息为服务请求端当前所在地的天气数据的情况，可以定位服务请求端的当前位置，基于该当前位置确定服务请求端所在地，进而获取服务请求端所在地的天气数据。
92.针对服务请求端为非网约车平台用户的情况，通过上述方式在向服务请求端推送出行服务之后，有助于将非网约车平台用户转换为网约车平台的新用户。这里，应理解，针对服务请求端为网约车平台用户的情况，也可以基于服务请求端当前所处的场所类型以及服务请求端所在地的天气数据来进行后续的服务推送。
93.在另一示例中，针对出行场景信息为服务请求端当前所处的下单阶段的情况，可以基于服务请求端针对在服务请求端130上显示的出行订单的操作界面的操作，来确定服务请求端当前所处的下单阶段。
94.作为示例，上述下单阶段可包括但不限于以下的任意一种或多种：出行订单预备阶段、出行订单下达阶段、出行订单完成阶段。这里，出行订单预备阶段可包括但不限于以下的任意一种或多种：进入出行订单的操作界面、出行订单的地点(出发地或目的地)输入、出行订单的服务类型选择。出行订单下达阶段可包括但不限于以下的任意一种或多种：对操作界面中的下单选项选择(即，呼叫阶段)、等待司机应答、等待接驾、送驾阶段。出行订单完成阶段可包括但不限于以下的任意一种或多种：达到目的地、接收到出行订单完成请求。
95.针对服务请求端为网约车平台用户的情况，可以基于上述方式来获取服务请求端当前的出行场景信息以进行后续的服务推送。
96.步骤s102，根据服务请求端当前的出行场景信息，确定服务请求端当前所在的目标出行场景。
97.示例性地，在本申请中预先设定了多个类型的出行场景，在该步骤中根据所获取的服务请求端当前的出行场景信息，来确定服务请求端当前处于多个类型的出行场景中的
哪一个出行场景，将服务请求端当前处于的出行场景确定为服务请求端当前所在的目标出行场景。
98.作为示例，多个类型的出行场景可包括但不限于以下的任意一种或多种：通勤场景、交通枢纽场景、休闲娱乐场景、商务场景、订单预备场景、订单下达场景、订单完单场景、易分配订单的天气场景、不易分配订单的天气场景。
99.例如，针对服务请求端当前的出行场景信息为服务请求端当前所处的场所类型的情况，可以将与服务请求端当前所处的场所类型对应的出行场景确定为服务请求端当前所在的目标出行场景。例如，当服务请求端当前所处的场所类型为通勤场所时，则可确定服务请求端当前所在的目标出行场景为通勤场景，当服务请求端当前所处的场所类型为交通枢纽场所时，则可确定服务请求端当前所在的目标出行场景为交通枢纽场景，对此，本申请不再一一举例。
100.针对服务请求端当前的出行场景信息为服务请求端当前所处的下单阶段的情况，可以将与服务请求端当前所处的下单阶段对应的出行场景确定为服务请求端当前所在的目标出行场景，例如，当服务请求端当前处于出行订单预备阶段时，则可确定服务请求端当前所在的目标出行场景为订单预备场景，当服务请求端当前处于出行订单下达阶段时，则可确定服务请求端当前所在的目标出行场景为订单下达场景，当服务请求端当前处于出行订单完成阶段时，则可确定服务请求端当前所在的目标出行场景为订单完单场景。
101.针对服务请求端当前的出行场景信息为服务请求端当前所在地的天气数据的情况，可以预先确定在不同天气数据下的订单分配情况(是供大于求还是供小于求的情况)，基于订单分配情况确定出易分配订单的天气场景(即，订单为供大于求的情况以及与该情况对应的天气参数)以及不易分配订单的天气场景(即，订单供小于求的情况以及与该情况对应的天气参数)。在此情况下，在获取到服务请求端当前所在地的天气数据之后，基于该天气数据与上述天气场景对应的天气参数的匹配结果，确定出确定服务请求端当前所在的目标出行场景。
102.在本申请的一实施例中，通过对上述多种类型的出行场景进行分析获知部分出行场景存在返程需求，例如，通勤场景、休闲娱乐场景，因此，针对这类出行场景来推送目标出行服务，有助于促进出行闭环的形成，更易被服务请求端所接受。
103.图3示出了本申请实施例所提供的存在返程需求的出行场景的示例。
104.参照图3所示，在本示例中，存在返程需求的出行场景可包括但不限于通勤场景、休闲娱乐场景。
105.休闲娱乐场景和通勤场景存在一个共同特点是：服务请求端都有“来和去”的需求，但是通过对不同出行场景的分析发现在上述出行场景下服务请求端完成出行闭环的比例并不高，新用户尤其偏低。针对上述问题，本申请的服务推送方法在服务请求端处于存在返程需求的出行场景中时，向服务请求端推送目标出行服务，即，采用有针对性的出行服务推送来促进出行闭环的完成以提升完单量。
106.返回图2，步骤s103，查找目标出行场景的类型所对应的目标出行服务。
107.这里，目标出行场景对应于多种出行服务，可从多种出行服务中查找与该目标出行场景对应的目标出行服务。各出行服务可指引导服务请求端使用相应的出行方式的服务，示例性地，出行服务可包括但不限于以下的任意一种或多种：引导服务请求端使用快车
的服务、引导服务请求端使用拼车的服务、引导服务请求端使用顺风车的服务。
108.在一示例中，多种出行服务可包括向服务请求端推荐用于引导服务请求端使用相应的出行方式的激励策略，例如，针对出行方式(如快车、拼车、顺风车)派发优惠券、提升针对出行方式的接单速度、缩短针对出行方式的接驾等待时长等。
109.步骤s104，向服务请求端推荐目标出行服务。
110.这里，在目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级，其中，推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的。这里，目标出行服务的推荐优先级高于其他出行服务的推荐优先级可指目标出行服务的推荐优先级大于设定值，或者目标出行服务的推荐优先级大于全部出行服务的推荐优先级的中间值等，本申请并不限于目标出行服务的推荐优先级是全部出行服务的推荐优先级中的最大值这一种情况。
111.在该步骤中，通过对出行场景的精细化分析，寻找有助于使服务请求端使用所推送的目标出行服务的优势场景，以满足用户的异质化需求。
112.一种情况，可直接基于每种类型的出行服务的供给饱和度和订单执行量计算各出行服务的推荐优先级，以基于推荐优先级来确定目标出行服务。
113.参照图4所示，为本申请实施例所提供的查找目标出行场景的类型所对应的目标出行服务的一种方式，具体执行过程为：
114.步骤s201，分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量。
115.这里，获取每个类型的出行服务的供给饱和度和订单执行量的时机可以在本申请的服务推送方法执行的时候，也可以是在执行本申请的服务推送方法之前完成的。
116.示例性地，订单执行量可包括但不限于以下的任意一个或多个参数：用车呼叫量、用车去重呼叫量、订单数量(即下单数量)、订单资源(如订单的金额)、完单数量。作为示例，供给饱和度可包括但不限于各出行方式(如快车、拼车等车型)的供给能力。
117.步骤s202，针对每个类型的出行服务，根据该出行服务的供给饱和度和订单执行量计算该出行服务的推荐优先级。
118.这里，推荐优先级可指对应的出行服务被推荐给服务请求端的先后顺序。推荐优先级与供给饱和度呈负相关性，例如，供给饱和度越高，则推荐优先级越低，供给饱和度越低，则推荐优先级越高。此外，推荐优先级与订单执行量呈负相关性，例如，订单执行量所指示的数量(如上述所列举的呼叫量、下单数量、完单数量)越多，则推荐优先级越低，订单执行量所指示的数量越少，则推荐优先级越高。也就是说，上述计算出的推荐优先级越高，表明服务请求端使用该高推荐优先级对应的出行服务的可能性更高，即，有助于提升服务请求端对高推荐优先级对应的出行服务的使用率。
119.除上述方式之外，还可以从多个出行服务中预先选出一参考服务，基于多个出行服务中的除该参考服务之外的其他服务与该参考服务的对比情况，来确定各出行服务的推荐优先级。示例性地，参考服务可指网约车平台中业务量大(可以是订单执行量最大)的出行方式。
120.例如，针对多个出行服务中的每个出行服务，获取在不同出行场景下，使用该出行服务的第一历史出行订单数据以及使用参考服务的第二历史出行订单数据。针对每个出行
场景，通过对比第一历史出行订单数据和第二历史出行订单数据，确定使用该出行服务在该出行场景下的服务使用率(也可指订单执行量可提升程度)。
121.例如，可以统计该出行服务、参考服务在不同出行场景下的订单数量(也可以呼叫量或者完单数量等)，针对每个出行场景，将该出行场景下参考出行方式的订单数量作为参考值，确定参考服务的订单数据与该出行服务的订单数量的差值，将该差值确定为用于衡量使用该出行服务在该出行场景下的服务使用率的指标值。
122.基于目标出行场景下各出行服务的上述指标值的大小来确定各出行服务的推荐优先级。例如，在目标出行场景下，出行服务的指标值越大，则出行服务的推荐优先级越高，出行服务的指标值越小，则出行服务的推荐优先级越低。
123.在上述示例中，通过将不同出行服务进行横向比较，确定各出行服务在不同出行场景下的可提升空间，将可提升空间较大的出行服务确定为目标出行场景对应的目标出行服务。
124.步骤s203，根据不同出行服务的推荐优先级，从全部的出行服务中选择出目标出行场景所对应的目标出行服务。
125.例如，可以针对所有类型的出行服务按推荐优先级高低进行排序，将排在首位的出行服务确定为目标出行场景所对应的目标出行服务。但本申请不限于此，上述目标出行服务还可以包括多种出行服务，例如，可在针对所有类型的出行服务按推荐优先级从高到低进行排序之后，将排在预定数量之前(如排在前三位)的出行服务确定为目标出行场景所对应的目标出行服务。
126.另一种情况，可基于每种类型的出行服务的供给饱和度排名和订单执行量排名计算各出行服务的推荐优先级，以基于推荐优先级来确定目标出行服务。
127.参照图5所示，为本申请实施例提供的查找目标出行场景的类型所对应的目标出行服务的另一种方式，具体执行过程为：
128.步骤s301，分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量。
129.这里，获取每个类型的出行服务的供给饱和度和订单执行量的时机可以在本申请的服务推送方法执行的时候，也可以是在执行本申请的服务推送方法之前完成的。
130.示例性地，订单执行量可包括但不限于以下的任意一个或多个参数：用车呼叫量、用车去重呼叫量、订单数量、订单资源、完单数量。作为示例，供给饱和度可包括但不限于各出行方式的供给能力。
131.步骤s302，根据每个类型的出行服务的供给饱和度和订单执行量，分别形成关于供给饱和度的排名和关于订单执行量的排名。
132.例如，可以针对每个类型的出行服务的供给饱和度，按照供给饱和度由高到低或者由低到高的顺序进行排名，也可以针对每个类型的出行服务的订单执行量，按照订单执行量所指示的数量由多到少或者由少到多的顺序进行排名。
133.步骤s303，针对每个类型的出行服务，根据该出行服务关于供给饱和度的排名和关于订单执行量的排名，确定该出行服务的推荐优先级。
134.这里，推荐优先级与供给饱和度呈负相关性，例如，供给饱和度越高，则推荐优先级越低，供给饱和度越低，则推荐优先级越高。针对关于供给饱和度的排名为按照供给饱和
度由高到低排名的情况，则排名越靠前的出行服务，对应的推荐优先级越低，排名越靠后的出行服务，对应的推荐优先级越高。针对关于供给饱和度的排名为按照供给饱和度由低到高排名的情况，则排名越靠前的出行服务，对应的推荐优先级越高，排名越靠后的出行服务，对应的推荐优先级越低。
135.此外，推荐优先级与订单执行量呈负相关性，例如，订单执行量所指示的数量越多，则推荐优先级越低，订单执行量所指示的数量越少，则推荐优先级越高。针对按照订单执行量所指示的数量由多到少排名的情况，则排名越靠前的出行服务，对应的推荐优先级越低，排名越靠后的出行服务，对应的推荐优先级越高。针对按照订单执行量所指示的数量由少到多排名的情况，则排名越靠前的出行服务，对应的推荐优先级越高，排名越靠后的出行服务，对应的推荐优先级越低。
136.步骤s304，根据不同出行服务的推荐优先级，从全部的出行服务中选择出目标出行场景所对应的目标出行服务。
137.例如，可以针对所有类型的出行服务按推荐优先级高低进行排序，将排在首位的出行服务确定为目标出行场景所对应的目标出行服务。但本申请不限于此，上述目标出行服务还可以包括多种出行服务，例如，可在针对所有类型的出行服务按推荐优先级从高到低进行排序之后，将排在预定数量之前的出行服务确定为目标出行场景所对应的目标出行服务。
138.应理解上述所列举的确定目标出行场景所对应的目标出行服务的方式仅为示例，本申请不限于此，还可以通过其他方式来确定目标出行场景所对应的目标出行服务。
139.参照图6所示，为本申请实施例提供的另一种服务推送方法的流程示意图，该方法可以由服务推送系统100中的服务器或者服务请求端来执行，具体执行过程为：
140.步骤s401，获取服务请求端当前的出行场景信息。
141.在一实施例中，可以基于服务请求端所发出的出行订单操作请求，获取服务请求端当前的出行场景信息。作为示例，出行场景信息可包括但不限于以下的任意一种或多种：服务请求端当前所处的场所类型、服务请求端当前所处的下单阶段、服务请求端当前所在地的天气数据。
142.步骤s402，根据出行场景信息，确定服务请求端当前所在的目标出行场景。
143.其中，步骤s401至s402的描述可以参照上述图2所示的步骤s101至s102的描述，并且能达到相同的技术效果，对此不做赘述。
144.步骤s403，根据用户留存时间和服务请求端在不同时间的出行订单数据，确定服务请求端当前所处的服务阶段。
145.在一示例中，用户留存时间可以根据不同服务请求端使用出行服务(可指全部出行服务)的出行订单数据来确定。这里，上述不同服务请求端可指包含该服务请求端的多个服务请求端、也可以指不包含该服务请求端的多个服务请求端。
146.作为示例，服务请求端在不同时间的出行订单数据可包括但不限于以下的一种或者多种：服务请求端在不同时间使用出行服务的订单数量、完单数量、用车呼叫量、去重用车呼叫量。
147.基于此，以出行订单数据为订单数量为例，可以通过以下方式来确定用户留存时间：根据不同服务请求端使用全部出行服务的订单数量，计算关于服务请求端在不同时间
的订单数量的拐点，根据拐点所对应的时间，确定用户留存时间。在本申请中，用户留存时间可指用于表征服务请求端留存率趋于稳定的时间拐点。
148.在现有技术中，用户留存的定义通常是基于月粒度的留存，其无法真实反应用户流失的重要时间点，导致基于此留存定义的模型拟合效果不佳，对业务指导意义不足。
149.针对上述问题，在本申请中提出一种精确确定用户留存时间点的方法，将之前基于月粒度的留存聚焦到天粒度，准确抓取到用户流失的关键节点。
150.参照图7所示，为本申请实施例提供的确定用户留存时间的示例图，下面结合图7来介绍确定用户留存时间的方式。应理解，图7所列举的确定用户留存时间的方式仅为一示例，本申请不限于此，还可以通过其他方式来确定用于表征服务请求端留存率趋于稳定的时间拐点。
151.参照图7所示的示例，假设预定时间段为30天，出行订单数据为完单数量，基于不同服务请求端使用全部出行服务的完单数量，通过统计服务请求端首次完单后，在后续预定时间段内的再次完单(也可以是再次呼叫)与发生首单的时间间隔，确定服务请求端留存率趋于稳定的拐点，以此作为用户留存的时间点，即，将发生首单的时间点与服务请求端留存率趋于稳定的拐点之间的时间间隔确定为用于表征服务请求端留存率趋于稳定的时间拐点。
152.在图7所示的示例中，横坐标为天数，纵坐标为完单留存率。首先基于完单数量，确定首单的完成时间为预定时间段的起始时间点的总体完单数量，再统计每日的留存完单数量，针对每日中的任一日，将该任一日的留存完单数量与总体完单数量的比值确定为该任一日的完单留存率。
153.图7中所示的各散点即为每日的完单留存率，可以利用各种拟合方式获得图中所示的拟合曲线，以确定该拟合曲线中完单留存率趋于稳定的拐点，如图中所示的时间点a，由此确定出用于表征服务请求端留存率趋于稳定的时间拐点。在图7所示的示例中，通过对30天的出行订单数据进行分析，将14天作为用户留存时间。
154.应理解，除上述利用拟合曲线来确定拐点的方式之外，还可以通过其他方式来寻找完单留存率趋于稳定的拐点。例如，可以计算相邻两日的完单留存率的差值，并将该差值与预设值进行比较，如果存在连续多日的上述差值小于预设值，则将连续多日的第一日确定为完单留存率趋于稳定的拐点。
155.此外，在本申请的一实施例中，该服务推送方法可还包括：预先划分多个服务阶段，在此情况下，根据用户留存时间和服务请求端在不同时间的出行订单数据，确定服务请求端当前所处多个服务阶段中的哪一服务阶段。
156.这里，应理解，步骤403与步骤401～步骤402的执行顺序不分先后。
157.在该步骤中，以出行订单数据包括订单数量为例，获取预定时间段内的服务请求端使用出行服务所下达的订单数量，这里，预定时间段可基于用户留存时间来确定；基于所获取的订单数量与不同服务阶段对应的匹配条件的匹配结果，确定服务请求端当前所处的服务阶段。本申请不限于此，也可以获取位于当前时间之前的至少一个用户留存时间内的用车呼叫量、去重用车呼叫量、完单数量，基于所提取的上述参数与对应匹配条件的匹配结果，确定服务请求端当前所处的服务阶段。
158.作为示例，可以提取位于当前时间之前的、且与当前时间相邻的一个用户留存时
间内(如最近14天)的用车呼叫量，如果该用车呼叫量为零，则确定服务请求端处于流失期，如果该用车呼叫量不为零，则提取位于该一个用户留存时间之前的、且与该一个用户留存时间相邻的用户留存时间内(如最近14之前的14天)的去重用车呼叫量，如果该去重用车呼叫量不小于设定呼叫量，则确定服务请求端处于活跃期，如果该去重用车呼叫量小于设定呼叫量，则确定服务请求端处于激活期。
159.参照图8所示，为本申请实施例提供的多个服务阶段的示例图，下面将参照图8来介绍确定服务请求端当前所处的服务阶段的过程。
160.在上述所确定的用户留存时间的基础上，本申请的服务推送方法对不同服务阶段的定义进行了重建，根据服务请求端在不同的产品体验阶段，构建多个服务阶段：新生期、活跃期、流失期、激活期和潜在用户，并对服务请求端在不同服务阶段之间的切换进行了定义，形成一套完整的服务阶段流转系统。
161.示例性地，以用户留存时间为14天为例，服务请求端完成首单即成为网约车平台的新用户，可以将服务请求端完成首单之后的14天定义为新生期，基于出行订单数据，根据服务请求端在新生期内的去重用车呼叫量进行判断，如果在新生期内的去重用车呼叫量不小于(大于或者等于)设定呼叫量(包括但不限于2次)，则该服务请求端进入活跃期，如果在新生期内的去重用车呼叫量小于设定呼叫量，则该服务请求端进入流失期。针对处于活跃期的服务请求端，根据活跃期内服务请求端历史14天用车呼叫量进行判断，如果用车呼叫量为零，则该服务请求端进入流失期，如果用车呼叫量不为零，则该服务请求端继续保留在活跃期。针对处于流失期的服务请求端，从发生用车呼叫即日起(即，产生用车呼叫量)，该服务请求端进入激活期，如果处于流失期的服务请求端一直未发生用车呼叫，则该服务请求端继续保留在流失期。针对处于激活期的服务请求端，根据服务请求端在激活期内的去重呼叫量进行判断，如果去重呼叫量不小于设定呼叫量，则该服务请求端进入活跃期，如果去重呼叫量小于设定呼叫量，则该服务请求端进入流失期。
162.参见图6所示的步骤s404，分别获取目标出行场景中，每个类型的出行服务与服务请求端当前所处的服务阶段对应的服务偏好的匹配度。
163.这里，不同的服务阶段对应的服务偏好是不同的，可以利用各种算法来计算每个类型的出行服务与服务请求端当前所处的服务阶段对应的服务偏好的匹配度。
164.基于上述所构建的服务阶段流转系统，来对处于不同的服务阶段的服务请求端，提供有针对性的服务，以满足服务请求端的异质需求、提升服务请求端活跃度、降低服务请求端流失率。
165.步骤s405，根据每个出行服务的匹配度和推荐优先级，从全部的出行服务中选择出目标出行场景所对应的目标出行服务。
166.例如，从目标出行场景所对应的候选出行服务中选择出目标出行场景所对应的目标出行服务，候选出行服务的推荐优先级高于其他出行服务的推荐优先级。即，可以基于目标出行场景对应的不同出行服务的推荐优先级筛选出候选出行服务，然后基于候选出行服务与服务请求端当前所处的服务阶段对应的服务偏好的匹配度，来从候选出行服务中选择出目标出行场景所对应的目标出行服务。应理解，本申请不限于，也可以是将不同出行服务中与服务请求端当前所处的服务阶段对应的服务偏好的匹配度高的出行服务确定为候选出行服务，然后基于各候选出行服务的推荐优先级从中选择出目标出行场景所对应的目标
出行服务。
167.步骤s406，向服务请求端推荐目标出行服务。
168.这里，目标出行场景对应于多种出行服务，可从多种出行服务中查找与该目标出行场景对应的目标出行服务。在目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级，其中，推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的。
169.其中，步骤s405至s406的描述可以参照上述图2所示的步骤s103至s104的描述，并且能达到相同的技术效果，对此不做赘述。
170.参照图9所示，为本申请实施例提供的再一种服务推送方法的流程示意图，该方法可以由服务推送系统100中的服务器110来执行，也可以由服务请求端来执行，具体执行过程为：
171.步骤s501，获取服务请求端当前的出行场景信息。
172.在一实施例中，可以在接收到服务请求端所发出的出行订单操作请求后，获取服务请求端当前的出行场景信息。作为示例，出行场景信息可包括但不限于以下的任意一种或多种：服务请求端当前所处的场所类型、服务请求端当前所处的下单阶段、服务请求端当前所在地的天气数据。
173.步骤s502，根据出行场景信息，确定服务请求端当前所在的目标出行场景。
174.其中，步骤s501至s502的描述可以参照上述图2所示的步骤s101至s102的描述，并且能达到相同的技术效果，对此不做赘述。
175.步骤s503，基于用户留存时间以及服务请求端的出行订单数据，确定服务请求端所属的用户类型。
176.在一示例中，用户留存时间可以根据不同服务请求端使用全部出行服务的出行订单数据来确定。作为示例，服务请求端在不同时间的出行订单数据可包括但不限于以下的一种或者多种：服务请求端在不同时间使用出行服务的订单数量、完单数量、用车呼叫量、去重用车呼叫量。
177.基于此，以出行订单数据为订单数量为例，可以通过以下方式来确定用户留存时间：根据不同务请求端使用全部出行服务的订单数量，计算关于服务请求端在不同时间的订单数量的拐点，根据拐点所对应的时间，确定用户留存时间。在本申请中，用户留存时间可指用于表征服务请求端留存率趋于稳定的时间拐点。
178.示例性地，可以通过以下方式来确定服务请求端所属的用户类型：基于用户留存时间，从服务请求端的出行订单数据中提取服务请求端的出行特征信息，将所提取的服务请求端的出行特征信息输入到用户分类模型，以获得服务请求端所属的用户类型。
179.在制定服务请求端的相关策略时，针对不同用户类型的服务请求端开展个性化服务，可以有效提升服务效率、合理分配资源、提升服务请求端活跃度。
180.作为示例，服务请求端的出行特征信息可包括但不限于以下的一种或多种：服务请求端的最近完单距当前时间的时长、位于当前时间之前且相邻的用户留存时间内的完单频次、位于当前时间之前且相邻的用户留存时间内的完单金额、历史完单量。本申请在服务请求端的出行特征信息中增加了服务请求端的历史完单量，用以体现服务请求端长期维度的活跃程度。
181.以用户留存时间为14天为例，服务请求端的出行特征信息可包括服务请求端的最近完单距当前时间的时长、最近14天的完单频次、最近14天的完单金额、历史完单量。
182.在一可选示例中，用户分类模型可包括但不限于rfm模型，还可以利用其他训练好的分类模型来确定服务请求端所属的用户类型。这里，不同用户类型可用于表征服务请求端的活跃度，以针对不同活跃度的服务请求端制定相应的运营策略，提升服务请求端的出行服务使用频次以及完单量。
183.这里，应理解，步骤503与步骤501～步骤502的执行顺序不分先后。
184.步骤s504，分别获取目标出行场景中，每个类型的出行服务与服务请求端所属的用户类型的匹配度。
185.这里，不同的用户类型对应的服务请求端活跃度(即，服务请求端使用全部出行服务的频次)不同，换言之，不同用户类型的服务请求端对出行服务的使用频次需求不同，匹配度越高，表明相匹配的出行服务越能够满足与其匹配的用户类型的服务请求端对出行服务的使用频次需求。可以利用各种算法来计算每个类型的出行服务与服务请求端所属的用户类型的匹配度。
186.步骤s505，根据不同出行服务的匹配度和推荐优先级，从全部的出行服务中选择出目标出行场景所对应的目标出行服务。
187.例如，从目标出行场景所对应的候选出行服务中选择出目标出行场景所对应的目标出行服务，候选出行服务的推荐优先级高于其他出行服务的推荐优先级。即，可以基于目标出行场景对应的不同出行服务的推荐优先级筛选出候选出行服务，然后基于候选出行服务与服务请求端所属的用户类型对应的服务请求端活跃度的匹配度，来从候选出行服务中选择出目标出行场景所对应的目标出行服务。应理解，本申请不限于，也可以是将不同出行服务中与服务请求端所属的用户类型对应的服务请求端活跃度的匹配度高的出行服务确定为候选出行服务，然后基于各候选出行服务的推荐优先级从中选择出目标出行场景所对应的目标出行服务。
188.步骤s506，向服务请求端推荐目标出行服务。
189.这里，目标出行场景对应于多种出行服务，可从多种出行服务中查找与该目标出行场景对应的目标出行服务。
190.其中，步骤s505至s506的描述可以参照上述图2所示的步骤s103至s104的描述，并且能达到相同的技术效果，对此不做赘述。
191.结合上述确定了服务请求端当前所处的服务阶段的情况，此时可以结合每个类型的出行服务与服务请求端所属的用户类型的匹配度、每个类型的出行服务与服务请求端当前所处的服务阶段对应的服务偏好的匹配度、每个类型的出行服务推荐优先级，来确定目标出行场景所对应的目标出行服务。
192.在一示例中，可以将每个类型的出行服务与服务请求端所属的用户类型的匹配度、与服务请求端当前所处的服务阶段对应的服务偏好的匹配度中匹配度最高的出行服务确定为目标出行场景所对应的目标出行服务。或者，也可以将每个类型的出行服务与服务请求端所属的用户类型的匹配度、与服务请求端当前所处的服务阶段对应的服务偏好的匹配度中匹配度最高的出行服务确定为候选出行服务，然后基于该候选出行服务的推荐优先级选择出目标出行服务。但本申请不限于此，也可以将综合匹配度最高(如每个出行服务针
对服务阶段和针对用户类型的两个匹配度的均值最大)的出行服务确定为目标出行场景所对应的目标出行服务。或者，也可以将推荐优先级高的出行服务确定为候选出行服务，然后将候选出行服务中综合匹配度最高的候选出行服务确定目标出行服务。本申请对此不再一一列举。
193.此外，在本申请的另一实施例中，上述服务推送方法可还包括：确定不同类型的出行服务的出行订单全流程中的各环节所对应的漏斗指标，基于漏斗指标确定在出行订单全流程中用于触发推送交互信息的关键环节。
194.作为示例，该关键环节可指在出行订单全流程中影响完单率(或完单数量)的环节，例如，关键环节可包括但不限于出行订单全流程中用户转化率低的环节。
195.在此情况下，本申请的服务推送方法可还包括：响应于服务请求端下达的针对推荐的目标出行服务的下单请求，生成出行订单；将出行订单分配给服务提供方，并在将出行订单分配给服务提供方之后，在服务提供方接乘到持有服务请求端的服务请求方之前，向服务请求端发送用于促使出行订单完成的交互信息，以引导服务请求端完成该出行订单。这里，在将出行订单分配给服务提供方之后，在服务提供方接乘到持有服务请求端的服务请求方之前的阶段中，出行订单的出行订单流程到达关键环节时，向服务请求端发送交互信息。作为示例，该交互信息可包括但不限于以下的一种或者多种：用于引导服务请求端完单的各种激励策略，如派发代金券、满减券、折扣券等。
196.参照图10所示，为本申请提供的确定在出行订单全流程中用于触发推送交互信息的关键环节的示例图。
197.用户转化是用户增长的关键环节，通过梳理服务请求端出行订单全流程(也可称为呼叫完单全流程)，定义多个漏斗指标并进行监控，实时获取用户转化数据。并且通过对用户漏斗转化的逐步拆解，查看用户需求满足度，找到用户体验痛点，排除增长干扰，突破增长瓶颈。
198.在本示例中，以“两口价”和“拼成乐”的呼叫完单全流程为例，来介绍确定关键环节的过程。
199.针对“两口价”的呼叫完单全流程，该呼叫完单全流程共包括9个漏斗，共确定4个漏斗指标，例如，应答率、应答后取消率、呼叫愿拼率和完单率。
200.作为示例，应答率可指应答量与呼叫量的比值，应答后取消率可指取消量与应答量的比值，呼叫愿拼率可指打勾呼叫单量与可拼呼叫单量的比值，完单率可指完单量与呼叫量的比值。
201.针对“拼成乐”的呼叫完单全流程，该呼叫完单全流程共包括8个漏斗，共确定5个漏斗指标，例如，冒泡发单率、应答率、应答后取消率、冒泡率和完单率。
202.作为示例，冒泡发单率可指呼叫量与冒泡量的比值，冒泡率可指拼成乐冒泡量与青菜拼车项导pv的比值。
203.将上述所确定的各漏斗指标分别与对应的阈值进行比较，将小于对应的阈值的漏斗指标所对应的转换环节确定为在出行订单全流程中用于触发推送交互信息的关键环节，从而针对所确定的关键环节来推送服务以提升完单率。
204.例如，假设针对“两口价”的呼叫完单全流程进行分析，确定其应答后取消率小于对应的阈值，则可确定由司机应答至接驾的环节为关键环节，在该环节造成用户流失的原
因可能是等待接驾的时间过长，对此，可以在服务请求端的出行订单流程到达司机应答环节时，向服务请求端发送用于促使出行订单完成的交互信息，以用于促使出行订单完单的服务(如补贴券、消费券)，以填补服务请求端的等待空隙。
205.除上述方式之外，还可以对某一环节下的不同用户群体(如新用户和老用户)进行对比，来确定不同用户群体的漏斗指标。例如，如果在“两口价”的呼叫完单全流程中，新用户的应答后取消率高于老用户的应答后取消率，表明新用户的等待耐心更差，此时可以在新用户的出行订单流程到达司机应答环节时，向新用户推送用于促使出行订单完单的服务。
206.在本申请的服务推送方法中，从用户获取、转化、提频、留存多个角度进行分析，并重构了服务阶段和用户留存定义，以用户需求个性化、场景精细化运营为手段，打造了一套完整的网约车服务请求端增长体系。
207.参照图11所示，为本申请实施例提供的再一种服务推送方法的流程示意图，该方法可以由服务推送系统100中的服务请求端130来执行，也可以由服务器110来执行，具体执行过程为：
208.步骤s601，获取服务请求端当前的出行场景信息。
209.作为示例，出行场景信息可包括但不限于以下的任意一种或多种：服务请求端当前所处的场所类型、服务请求端当前所处的下单阶段、服务请求端当前所在地的天气数据。
210.在一示例中，获取服务请求端当前的出行场景信息的步骤可包括：响应于服务请求端接收用户输入的触控操作，确定当前是否处于预定的订单下达阶段；若当前处于预定的订单下达阶段，则获取服务请求端与预定的订单下达阶段对应的当前的出行场景信息；若没有当前处于预定的订单下达阶段，则不获取服务请求端当前的出行场景信息。
211.作为示例，预定的订单下达阶段可包括但不限于以下的任意一种：出行订单下达阶段、出行订单的地点输入阶段、出行订单的服务类型选择阶段。
212.步骤s602，根据出行场景信息，确定服务请求端当前所在的目标出行场景。
213.例如，针对上述方法由服务请求端130来执行的情况，服务请求端可将服务请求端当前的出行场景信息上传至服务器，再从服务器接收服务器针对接收的出行场景信息确定的服务请求端当前所在的目标出行场景。针对上述方法由服务器110来执行的情况，服务器110可以根据出行场景信息，确定服务请求端当前所在的目标出行场景。
214.步骤s603，查找目标出行场景的类型所对应的目标出行服务。
215.这里，在目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级，推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的。
216.其中，步骤s601至s603的描述可以参照上述图2所示的步骤s101至s103的描述，并且能达到相同的技术效果，对此不做赘述。
217.步骤s604，在图形用户界面上展示推荐使用目标出行服务的提示信息。
218.这里，图形用户界面为在服务请求端上所呈现的界面，可以利用各种显示方式来展示上述提示信息。该提示信息可包括用于引导服务请求端使用相应的出行方式的激励策略。针对上述方法由服务器110来执行的情况，服务器可产生推荐使用目标出行服务的提示信息，并将该提示信息发送至服务请求端，以在服务请求端进行展示。
219.作为示例，可在处于预定的订单下达阶段时，展示上述提示信息。例如，可在处于
出行订单下达阶段时，在图形用户界面的通知栏展示该提示信息，或者，在处于出行订单的地点输入阶段时，在地点输入框的周围显示提示信息，在处于出行订单的服务类型选择阶段时，在指示服务类型的标签的相邻标签展示该提示信息。应理解，可以利用各种方式来在图形用户界面上展示上述提示信息，本申请对此不做限定。
220.基于同一发明构思，本申请实施例中还提供了与图2所示的服务推送方法对应的服务推送装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述服务推送方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
221.参照图12所示，为本申请实施例提供的一种服务推送装置的示意图，该服务推送装置700包括：场景信息获取模块710、出行场景确定模块720、出行服务确定模块730、出行服务推荐模块740；其中，
222.场景信息获取模块710获取服务请求端当前的出行场景信息。
223.在一实施例中，场景信息获取模块710可以基于服务请求端所发出的出行订单操作请求，获取服务请求端当前的出行场景信息。
224.示例性地，出行订单操作请求可包括但不限于以下的任意一种或多种：出行订单下达请求、出行订单的地点输入请求、出行订单的服务类型选择请求、出行订单预备请求。
225.作为示例，出行场景信息可包括但不限于以下的任意一种或多种：服务请求端当前所处的场所类型、服务请求端当前所处的下单阶段、服务请求端当前所在地的天气数据。
226.出行场景确定模块720根据出行场景信息，确定服务请求端当前所在的目标出行场景。
227.示例性地，在本申请中预先设定了多个类型的出行场景，出行场景确定模块720根据所获取的服务请求端当前的出行场景信息，来确定服务请求端当前处于多个出行场景中的哪一个出行场景，将服务请求端当前处于的出行场景确定为服务请求端当前所在的目标出行场景。
228.作为示例，多个类型的出行场景可包括但不限于以下的任意一种或多种：通勤场景、交通枢纽场景、休闲娱乐场景、商务场景、订单预备场景、订单下达场景、订单完单场景、易分配订单的天气场景、不易分配订单的天气场景。
229.例如，针对服务请求端当前的出行场景信息为服务请求端当前所处的场所类型的情况，出行场景确定模块720可以将与服务请求端当前所处的场所类型对应的出行场景确定为服务请求端当前所在的目标出行场景。针对服务请求端当前的出行场景信息为服务请求端当前所处的下单阶段的情况，出行场景确定模块720可以将与服务请求端当前所处的下单阶段对应的出行场景确定为服务请求端当前所在的目标出行场景。
230.针对服务请求端当前的出行场景信息为服务请求端当前所在地的天气数据的情况，可以预先确定在不同天气数据下的订单分配情况，基于订单分配情况确定出易分配订单的天气场景、不易分配订单的天气场景。在此情况下，出行场景确定模块720在获取到服务请求端当前所在地的天气数据之后，基于该天气数据与上述天气场景对应的天气参数的匹配结果，确定出确定服务请求端当前所在的目标出行场景。
231.出行服务确定模块730查找目标出行场景的类型所对应的目标出行服务。
232.这里，目标出行场景对应于多种出行服务，可从多种出行服务中查找于该目标出行场景对应的目标出行服务。各出行服务可指引导服务请求端使用相应的出行方式的服
务。
233.这里，在目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级，其中，推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的。
234.出行服务推荐模块740向服务请求端推荐目标出行服务。
235.基于本申请的上述服务推送装置700，通过对出行场景的精细化分析，寻找有助于使服务请求端使用所推送的目标出行服务的优势场景，挖掘服务请求端增长机会点。
236.一种可能的实施方式中，出行服务确定模块730可直接基于每种类型的出行服务的供给饱和度和订单执行量计算各出行服务的推荐优先级，以基于推荐优先级来确定目标出行服务。
237.例如，出行服务确定模块730可分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量。示例性地，订单执行量可包括但不限于以下的任意一个或多个参数：用车呼叫量、用车去重呼叫量、订单数量、订单资源、完单数量。作为示例，供给饱和度可包括但不限于各出行方式(如快车、拼车等车型)的供给能力。
238.出行服务确定模块730针对每个类型的出行服务，根据该出行服务的供给饱和度和订单执行量计算该出行服务的推荐优先级。
239.这里，推荐优先级与供给饱和度呈负相关性，例如，供给饱和度越高，则推荐优先级越低，供给饱和度越低，则推荐优先级越高。此外，推荐优先级与订单执行量呈负相关性，例如，订单执行量所指示的数量越多，则推荐优先级越低，订单执行量所指示的数量越少，则推荐优先级越高。
240.出行服务确定模块730根据不同出行服务的推荐优先级，从全部的出行服务中选择出目标出行场景所对应的目标出行服务。例如，可以针对所有类型的出行服务按推荐优先级从高到低进行排序，将排在首位的出行服务确定为目标出行场景所对应的目标出行服务。
241.另一种可能的实施方式中，出行服务确定模块730可基于每种类型的出行服务的供给饱和度排名和订单执行量排名计算各出行服务的推荐优先级，以基于推荐优先级来确定目标出行服务。
242.例如，出行服务确定模块730分别获取目标出行场景中，每个类型的出行服务的供给饱和度和订单执行量，根据每个类型的出行服务的供给饱和度和订单执行量，分别形成关于供给饱和度的排名和关于订单执行量的排名。
243.例如，可以针对每个类型的出行服务的供给饱和度，按照供给饱和度由高到低或者由低到高的顺序进行排名，也可以针对每个类型的出行服务的订单执行量，按照订单执行量所指示的订单数量由多到少或者由少到多的顺序进行排名。
244.出行服务确定模块730针对每个类型的出行服务，根据该出行服务关于供给饱和度的排名和关于订单执行量的排名，确定该出行服务的推荐优先级。
245.这里，推荐优先级与供给饱和度呈负相关性，例如，供给饱和度越高，则推荐优先级越低，供给饱和度越低，则推荐优先级越高。针对关于供给饱和度的排名为按照供给饱和度由高到低排名的情况，则排名越靠前的出行服务，对应的推荐优先级越低，排名越靠后的出行服务，对应的推荐优先级越高。针对关于供给饱和度的排名为按照供给饱和度由低到
高排名的情况，则排名越靠前的出行服务，对应的推荐优先级越高，排名越靠后的出行服务，对应的推荐优先级越低。
246.此外，推荐优先级与订单执行量呈负相关性，例如，订单执行量所指示的数量越多，则推荐优先级越低，订单执行量所指示的数量越少，则推荐优先级越高。针对按照订单执行量所指示的数量由多到少排名的情况，则排名越靠前的出行服务，对应的推荐优先级越低，排名越靠后的出行服务，对应的推荐优先级越高。针对按照订单执行量所指示的数量由少到多排名的情况，则排名越靠前的出行服务，对应的推荐优先级越高，排名越靠后的出行服务，对应的推荐优先级越低。
247.出行服务确定模块730根据不同出行服务的推荐优先级，从全部的出行服务中选择出目标出行场景所对应的目标出行服务。
248.例如，可以针对所有类型的出行服务按推荐优先级高低进行排序，将排在首位的出行服务确定为目标出行场景所对应的目标出行服务。但本申请不限于此，上述目标出行服务还可以包括多种出行服务，例如，可在针对所有类型的出行服务按推荐优先级高低进行排序之后，将排在预定数量之前的出行服务确定为目标出行场景所对应的目标出行服务。
249.一种可能的实施方式中，本申请实施例提供的一种服务推送装置700可还包括：服务阶段确定模块，根据用户留存时间和服务请求端在不同时间的出行订单数据，确定服务请求端当前所处的服务阶段。
250.例如，用户留存时间可以使用全部出行服务的出行订单数据来确定。作为示例，服务请求端在不同时间的出行订单数据可包括但不限于以下的一种或者多种：服务请求端在不同时间使用出行服务的订单数量、完单数量、用车呼叫量、去重用车呼叫量。
251.基于此，以出行订单数据为订单数量为例，可以通过以下方式来确定用户留存时间：根据不同服务请求端使用全部出行服务的订单数量，计算关于服务请求端在不同时间的订单数量的拐点，根据拐点所对应的时间，确定用户留存时间。在本申请中，用户留存时间可指用于表征服务请求端留存率趋于稳定的时间拐点。
252.此外，在本申请的一实施例中，可预先划分多个服务阶段，在此情况下，服务阶段确定模块根据用户留存时间和服务请求端在不同时间的出行订单数据，确定服务请求端当前所处多个服务阶段中的哪一服务阶段。
253.以出行订单数据包括订单数量为例，提取位于当前时间之前的至少一个用户留存时间内的服务请求端的订单数量；基于所提取的订单数量与不同服务阶段对应的匹配条件的匹配结果，确定服务请求端当前所处的服务阶段。
254.作为示例，服务阶段确定模块可以提取位于当前时间之前的、且与当前时间相邻的一个用户留存时间内的用车呼叫量，如果该用车呼叫量为零，则确定服务请求端处于流失期，如果该用车呼叫量不为零，则提取位于该一个用户留存时间之前的、且与该一个用户留存时间相邻的用户留存时间内的去重用车呼叫量，如果该去重用车呼叫量不小于设定呼叫量，则确定服务请求端处于活跃期，如果该去重用车呼叫量小于设定呼叫量，则确定服务请求端处于激活期。
255.针对确定服务请求端当前所处的服务阶段的情况，出行服务确定模块730分别获取目标出行场景中，每个类型的出行服务与服务请求端当前所处的服务阶段对应的服务偏
好的匹配度，根据不同出行服务的匹配度和推荐优先级，从全部的出行服务中选择出所述目标出行场景所对应的目标出行服务。这里，不同的服务阶段对应的服务偏好是不同的。
256.一种可能的实施方式中，本申请实施例提供的一种服务推送装置700可还包括：用户类型确定模块，用于：基于用户留存时间以及服务请求端的出行订单数据，确定服务请求端所属的用户类型。
257.在一示例中，用户留存时间可以使用全部出行服务的出行订单数据来确定。基于此，以出行订单数据为订单数量为例，可以通过以下方式来确定用户留存时间：根据不同服务请求端使用全部出行服务的订单数量，计算关于服务请求端在不同时间的订单数量的拐点，根据拐点所对应的时间，确定用户留存时间。在本申请中，用户留存时间可指用于表征服务请求端留存率趋于稳定的时间拐点。
258.示例性地，用户类型确定模块可以通过以下方式来确定服务请求端所属的用户类型：基于用户留存时间，从服务请求端的出行订单数据中提取服务请求端的出行特征信息，将所提取的服务请求端的出行特征信息输入到用户分类模型，以获得服务请求端所属的用户类型。
259.作为示例，服务请求端的出行特征信息可包括但不限于以下的一种或多种：服务请求端的最近完单距当前时间的时长、位于当前时间之前且相邻的用户留存时间内的完单频次、位于当前时间之前且相邻的用户留存时间内的完单金额、历史完单量。本申请在服务请求端的出行特征信息中增加了服务请求端的历史完单量，用以体现服务请求端长期维度的活跃程度。
260.针对上述确定服务请求端所属的用户类型的情况，出行服务确定模块730分别获取目标出行场景中，每个类型的出行服务与服务请求端所属的用户类型的匹配度，根据不同出行服务的匹配度，从全部的出行服务中选择出目标出行场景所对应的目标出行服务。这里，不同的用户类型对应的服务请求端活跃度不同。
261.此外，一种可能的实施方式中，本申请实施例提供的一种服务推送装置700可还包括：关键环节确定模块，用于：确定不同类型的出行服务的出行订单全流程中的各环节所对应的漏斗指标，基于漏斗指标确定在出行订单全流程中用于触发推送交互信息的关键环节。
262.作为示例，该关键环节可指在出行订单全流程中影响完单率(或完单数量)的环节，例如，关键环节可包括但不限于出行订单全流程中服务请求端转化率低的环节。
263.在此情况下，出行服务推荐模块740可以响应于服务请求端下达的针对推送的目标出行服务的下单请求，生成出行订单，并在出行订单的出行订单流程到达关键环节时，向服务请求端推送交互信息，以引导服务请求端完成该出行订单。
264.基于同一发明构思，本申请实施例中还提供了与图11所示的服务推送方法对应的服务推送装置，由于本申请实施例中的装置解决问题的原理与本申请实施例上述服务推送方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。
265.请参阅图13，图13为本申请实施例提供的另一种服务推送装置的示意图，该另一种服务推送装置800包括：信息获取模块810、场景确定模块820、服务确定模块830、信息展示模块840，其中；
266.信息获取模块810获取服务请求端当前的出行场景信息。
267.例如，信息获取模块810可以响应服务请求端所下达的触控操作，确定当前是否处于预定的订单下达阶段。若当前处于预定的订单下达阶段，则获取服务请求端当前的出行场景信息。
268.这里，预定的订单下达阶段可包括但不限于以下的任意一种：出行订单下达阶段、出行订单的地点输入阶段、出行订单的服务类型选择阶段。
269.场景确定模块820根据出行场景信息，确定服务请求端当前所在的目标出行场景。
270.例如，服务请求端可将服务请求端当前的出行场景信息上传至服务器，再从服务器接收服务器针对接收的出行场景信息确定的服务请求端当前所在的目标出行场景。
271.其中，服务器110确定目标出行服务的过程已经在上述的图2至图9的各步骤中进行了详细的描述，并且能达到相同的技术效果，对此不做赘述。
272.服务确定模块830查找目标出行场景的类型所对应的目标出行服务。
273.这里，在目标出行场景中，目标出行服务的推荐优先级高于其他出行服务的推荐优先级，推荐优先级是根据不同出行服务的供需量的差别和订单执行量的差别确定的。
274.信息展示模块840在图形用户界面上展示推荐使用目标出行服务的提示信息。
275.关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。
276.请参阅图14，图14为本申请实施例所提供的一种电子设备的结构示意图。如图14中所示，所述电子设备900包括处理器910、存储器920和总线930。
277.所述存储器920存储有所述处理器910可执行的机器可读指令，当电子设备900运行时，所述处理器910与所述存储器920之间通过总线930通信，所述机器可读指令被所述处理器910执行时，可以执行如上述图2至图9所示方法实施例中的服务推送方法以及图11所示方法实施例中的服务推送方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。
278.本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时可以执行如上述图2至图9所示方法实施例中的服务推送方法以及图11所示方法实施例中的服务推送方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。
279.本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现上述图2至图9所示方法实施例中的服务推送方法以及图11所示方法实施例中的服务推送方法的步骤，具体实现方式可参见方法实施例，在此不再赘述。
280.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
281.在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
282.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个
网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
283.另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
284.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
285.最后应说明的是：以上所述实施例，仅为本申请的具体实施方式，用以说明本申请的技术方案，而非对其限制，本申请的保护范围并不局限于此，尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。