网约车监管方法、装置、服务器和存储介质与流程

1.本技术实施例涉及数据处理技术领域，尤其涉及一种网约车监管方法、装置、服务器和存储介质。


背景技术：

2.随着互联网技术的发展，以网约车业务为主要经营业务的网约车平台应运而生，由于当前存在较多网约车平台，不少网约车司机在不同网约车平台上开设不同的账号以赚取更多的收入。
3.目前，一些网约车平台为保证自身平台运力的充足，在提供车辆的情况下，与网约车司机签订劳动合同，要求网约车司机只能接指定本平台的订单。现有技术中，这类平台为减少平台损失，会在网约车处于无订单工作状态下，确定网约车的非主驾开关门信息，通过非主驾开关门信息来判断网约车是否存在私单私用行为，进而根据网约车是否存在私单私用行为对网约车进行管理。
4.然而，现有技术中的方案仅能确定出网约车是否存在私单私用行为，而无法对网约车私单私用行为造成的损失进行量化，导致网约车平台对网约车的管理存在精细化程度不高的问题。


技术实现要素：

5.本技术实施例提供一种网约车监管方法、装置、服务器和存储介质，以解决现有技术中存在的网约车平台对网约车的管理精细化程度不高的问题。
6.第一方面，本技术实施例提供一种网约车监管方法，包括：
7.获取签约车辆的在目标时间段内订单数据和上下线数据；
8.根据所述签约车辆的订单数据和上下线数据，确定出疑似接非本平台订单的目标签约车辆；
9.获取所述目标签约车辆在所述目标时间段内的监控数据；
10.根据所述目标签约车辆的订单数据、上下线数据和监控数据，确定所述目标签约车辆的非本平台接单数据。
11.第二方面，本技术实施例提供一种网约车监管装置，包括：
12.获取模块，用于获取签约车辆的在目标时间段内订单数据和上下线数据；
13.处理模块，用于根据所述签约车辆的订单数据和上下线数据，确定出疑似接非本平台订单的目标签约车辆；
14.所述获取模块，还用于获取所述目标签约车辆在所述目标时间段内的监控数据；
15.所述处理模块，还用于根据所述目标签约车辆的订单数据、上下线数据和监控数据，确定所述目标签约车辆的非本平台接单数据。
16.第三方面，本技术实施例提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述第一方面所述
的网约车监管方法。
17.第四方面，本技术实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的网约车监管方法。
18.本技术实施例提供的网约车监管方法、装置、服务器和存储介质，通过获取签约车辆的在目标时间段内订单数据和上下线数据，根据签约车辆的订单数据和上下线数据，确定出疑似接非本平台订单的目标签约车辆，获取目标签约车辆在目标时间段内的监控数据，根据目标签约车辆的订单数据、上下线数据和监控数据，确定目标签约车辆的非本平台接单数据。不仅可以识别出接非本平台订单的目标签约车辆，还可以识别出目标签约车辆的接非本平台订单的订单数量、总时长和时间段等，实现了对签约车辆非本平台接单行为的量化，有利于网约车平台制定出更加合理和具有针对性的管理策略，从而实现网约车平台对签约车辆的精细化管理，进而达到减少签约车辆的非本平台接单行为和减少网约车平台损失的目的。
19.应当理解，本部分所描述的内容并非旨在标识本技术的实施例的关键或重要特征，也不用于限制本技术的范围。本技术的其它特征将通过以下的说明书而变得容易理解。
附图说明
20.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
21.图1为本技术实施例提供的一种应用场景示意图；
22.图2为本技术实施例一提供的一种网约车监管方法的流程示意图；
23.图3为本技术实施例一提供的确定目标签约车辆的逻辑示意图；
24.图4为本技术实施例一提供的一种确定非本平台接单数据的逻辑示意图；
25.图5为本技术实施例三提供的一种网约车监管装置的结构示意图；
26.图6为本技术实施例四提供的一种服务器的结构示意图。
具体实施方式
27.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分的实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本技术保护的范围。
28.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“目标”、“候选”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这
些过程、方法、产品或设备固有的其它步骤或单元。
29.示例性地，图1为本技术实施例提供的一种应用场景示意图，如图1所示，本技术实施例所提供的网约车监管方法涉及服务器(对应网约车应用后台)和为与本平台签订劳动合同的网约车司机(简称平台司机)分配的网约车，网约车中安装有监控设备，如摄像头或拾音器等，网约车上还搭载有用户设备，如智能手机等，该用户设备中安装有网约车司机端app，平台司机通过登录网约车司机端app查询网约车应用后台派发的订单。
30.为加强对平台司机的管理，保证网约车平台自身运力的充足，现有技术中，网约车平台通过在网约车处于无订单工作状态下，确定网约车的非主驾开关门信息，通过非主驾开关门信息来判断网约车是否存在私单私用行为，现有技术中的方案虽然能判断网约车是否私单私用行为，进而根据网约车是否存在私单私用行为对网约车进行管理，如对存在私单私用行为的网约车进行惩罚等。但是，由于现有技术中并未涉及如网约车在其他平台接了多少订单、上线了多少时长等具体数据，因而无法对网约车私单私用行为对网约车平台造成的损失进行量化，从而导致网约车平台对网约车的管理存在一刀切的问题。
31.基于现有技术中存在的技术问题，本技术提供一种网约车监管方法，通过对网约车司机端app的反馈数据(包括订单数据和上下线数据)与设置在网约车内的监控设备采集到的监控数据进行对比分析，不仅可以识别出接非本平台订单的网约车，还可以识别出其接非本平台订单的订单数量、总时长和时间段等，进而根据订单数量、总时长和时间分布等，制定出更加合理和具有针对性的管理策略，从而实现对接非本平台订单的网约车的精细化管理，减少了本平台的损失。
32.实施例一
33.图2为本技术实施例一提供的一种网约车监管方法的流程示意图，本实施例的方法可以由本技术实施例所提供的网约车监管装置执行，该装置可以由软件和硬件的方式来实现，并可集成于如图1所示的服务器中。如图2所示，本实施例的网约车监管方法，包括：
34.s201、获取签约车辆的在目标时间段内订单数据和上下线数据。
35.由于网约车是通过司机端app进行接单的，因此，本实施例中，服务器会对平台司机在使用司机端app的过程中产生的数据，如订单数据、上下线数据和行驶里程数据等进行分类存储。如在数据库中为每一台签约车辆建立一个文件夹，并设置每个文件夹的名称为签约车辆标识，同时，在该文件夹中设置不同的子文件夹，以根据数据的类别和产生时间通过不同的子文件夹对订单数据、上下线数据和行驶里程数据等进行分类存储。
36.可选地，本实施例中，服务器通过第一数据库对订单数据和上下线数据进行存储。相应地，本步骤中，以目标时间段作为筛选条件，就可以从第一数据库中获取需要排查的签约车辆在目标时间段内产生的订单数据和上下线数据。
37.其中，订单数据，用于反映签约车辆接本平台订单的情况，订单数据中可以包括订单编号、订单开始时间和订单结束时间等。可选地，订单数据为订单汇总表。
38.上下线数据，用于反映签约车辆对应的平台司机在司机端app的上下线操作行为，上下线数据中上线时间和下线时间。可选地，上下线数据为上下线日志。可以理解的是，在工作期间平台司机是要始终保证司机端app为登录状态，平台司机要通过其他平台进行接单，则必然要进行登录平台的切换，此时，就会存在上下线操作行为，就会产生一条上下线数据。
39.目标时间段，是选定的分析签约车辆是否存在私单私用行为的过去的一个段时间，如特定的某一天。
40.本实施例中，可以根据实际需要确定需要排查的签约车辆的范围和签约车辆的订单数据及上下线数据的时间跨度，此处不做限制。
41.在一种可能的实施方式中，在每天的特定时间，如凌晨1：00，获取本平台所有签约车辆在前一天产生的订单数据和上下线数据，并进行分析，从而确定出疑似接非本平台订单的目标签约车辆和目标签约车辆的非本平台接单数据，从而提高管理的实时性、有效性和全面性。
42.s202、根据签约车辆的订单数据和上下线数据，确定出疑似接非本平台订单的目标签约车辆。
43.本步骤中，通过对s201中获取的签约车辆的订单数据和上下线数据进行统计和分析，确定出疑似接非本平台订单的签约车辆，即目标签约车辆。其中，非本平台订单中包括其他平台订单和线下订单。
44.可选地，在每日排查的场景中，本步骤中，可以先对各签约车辆的订单数据和上下线数据分别进行统计，确定出各签约车辆的日订单数、日在线总时长和未上线时段。进而，根据各签约车辆的日订单数、日在线总时长和未上线时段，通过条件筛选，确定出疑似接非本平台订单的目标签约车辆。
45.其中，日订单数，是指目标签约车辆当日接本平台订单的数量，由于每一笔订单都有一个唯一的订单号，因此，可以通过统计目标签约车辆的订单数据中的订单号的数量，确定目标签约车辆的日订单数。
46.日在线总时长，是指驾驶目标签约车辆的目标司机当日登录司机端app的总时长。未上线时段，是指驾驶目标签约车辆的目标司机当日在要求时间内未登录司机端app的一个或多个时间段。日在线总时长和未上线时段均可通过对驾驶目标签约车辆的目标司机的上下线数据进行分析得到。
47.例如，目标司机的上下线数据为：8：00上线，12：00下线，13：00上线，17：00下线，18：00上线，20：00下线，假设要求在线时间为8：00-20：00，则可以确定目标司机当日的日在线总时长为10小时，未上线时段为12：00-13：00和17：00-18：00。
48.本实施例中，可以预先根据需要设置相应的筛选条件。相应地，本步骤中，根据各签约车辆的日订单数、日在线总时长、未上线时段和预设的筛选条件，就可以通过条件筛选的方式，确定出疑似接非本平台订单的目标签约车辆。
49.可选地，筛选条件中包括第一筛选条件和第二筛选条件，第一筛选条件为日订单数低于订单数指标且在线时长低于在线时长指标，第二筛选条件为未上线时段中存在异常时段，相应地，则本实施例中可以各签约车辆的日订单数、日在线总时长和未上线时段，通过如下具体步骤确定目标签约车辆：
50.(1)将各签约车辆的日订单数与订单数指标以及日在线总时长与在线时长指标作比较，并将日订单数和日在线总时长满足第一筛选条件的签约车辆，确定为候选签约车辆。
51.(2)确定各候选签约车辆的未上线时段中是否存在异常时段，并将未上线时段满足第二筛选条件的候选签约车辆确定为目标签约车辆。
52.其中，异常时段为连续未上线时长超过预设时长的时段，预设时长可以根据签约
车辆完成一笔订单的平均时间进行设定，示例性地，若预设时长为30分钟，则上述目标司机的12：00-13：00和17：00-18：00均为异常时段。
53.示例性地，图3为本技术实施例一提供的确定目标签约车辆的逻辑示意图，由图3不难看出，通过上述方式逐渐缩小车辆的排查范围，从而最终达到筛选出疑似接非本平台订单的车辆的目的。
54.由于网约车平台对不同城市、不同季节或不同司机的日订单数、日在线总时长可能有不同的要求，因此，为提高管理的针对性和精细化程度，在执行上述步骤(1)之前可以先确定各签约车辆的订单数指标和在线时长指标。
55.在一种可能的实施方式中，以城市为单位，确定各签约车辆所在城市的人均日订单数和人均日在线总时长；根据人均日订单数和第一订单系数，确定各签约车辆的订单数指标；根据人均日在线总时长和第一时长系数，确定各签约车辆的在线时长指标。
56.其中，第一订单系数和第一时长系数均为0到1之间的数值。示例性地，通过求人均日订单数与第一订单系数的乘积，得到订单数指标，通过求人均日在线总时长与第一时长系数的乘积，得到在线时长指标。
57.可以理解的是，第一订单系数和第一时长系数与各城市的管理目标和管理要求有关，不同城市的第一订单系数和第一时长系数可以有不同。
58.通过本实施方式，将订单完成情况和在线时长情况与签约车辆所在城市的平均水平差异较大的签约车辆，确定为候选签约车辆。
59.在另一种可能的实施方式中，以签约车辆(或司机)为单位，确定各签约车辆的历史日均订单数和历史日均在线总时长；根据历史日均订单数和第二订单系数，确定各签约车辆的订单数指标；根据历史日均在线总时长和第二时长系数，确定各签约车辆的在线时长指标。
60.其中，第二订单系数和第二时长系数均为0到1之间的数值。示例性地，通过求历史日均订单数与第二订单系数的乘积，得到订单数指标，通过求历史日均在线总时长与第二时长系数的乘积，得到在线时长指标。
61.历史日均订单数和历史日均在线总时长，可以通过求解各签约车辆近期，如过去一周的日均订单数和日均在线总时长得到。
62.通过本实施方式，将订单完成情况和在线时长情况与历史平均水平差异较大的签约车辆，确定为候选签约车辆。
63.s203、获取目标签约车辆在目标时间段内的监控数据。
64.为保证网约车平台的服务质量和规范化，每台签约车辆上都设置有监控设备，该监控设备可以是音频设备，也可以是视频设备。监控设备采集的数据也会实时地传输到服务器后台，由服务器后台进行存储。如在数据库中为每一台签约车辆建立一个文件夹，以存储各签约车辆上监控设备产生的监控数据，可以理解的是，每一帧监控数据都有对应的采集时间。
65.可选地，本实施例中，服务器通过第二数据库对监控数据进行存储。相应地，本步骤中，以目标签约车辆的车辆标识和目标时间段为筛选条件，就可以从第二数据库获取目标签约车辆在目标时间段内的监控数据。
66.s204、根据目标签约车辆的订单数据、上下线数据和监控数据，确定目标签约车辆
的非本平台接单数据。
67.本实施例中，为进一步确认出目标签约车辆是否存在接非本平台订单的行为以及如果存在具体的接单情况是怎样的，本步骤中，需要对目标签约车辆的根据目标签约车辆的订单数据和上下线数据与监控数据作对比分析，从而确定目标签约车辆的非本平台接单数据。
68.其中，非本平台接单数据可以包括非本平台接单的订单数量、订单总时长和订单时间段等。
69.可以理解的是，若经过对比分析，确定目标签约车辆没有接非本平台订单，则非本平台接单数据的返回值可以为空或某个特定的值，如0。
70.可选地，本实施例中，可以先根据监控数据，确定目标签约车辆在目标时间段内的接送乘客数据和目标签约车辆上监控设备的状态数据；再根据目标签约车辆的订单数据、上下线数据、接送乘客数据和状态数据，确定目标签约车辆的非本平台接单数据。
71.其中，接送乘客数据用于反映目标签约车辆实际接送乘客的情况，如乘客数量、乘客的上车时间、下车时间等。需要说明的是，若监控设备为视频监控设备，则可以根据监控画面中是否有人以及人物外貌、动作等，确定不同乘客的上车时间和下车时间等。若监控设备为语音监控设备，则可以监控音频中是否有不同的声音以及对话的内容、开关车门的声音等，确定不同乘客的上车时间和下车时间等。
72.监控设备的状态数据用于反映监控设备的是否处于开机状态。需要说明的是，当车辆熄火时，监控设备是不工作的，因此，可以根据是否监控设备是否返回数据，确定监控设备是开机状态，还是关机状态，若某段时间是没有监控数据的，则可以确定该段时间监控设备为关机状态。
73.在一种可能的实施方式中，非本平台接单数据包括非本平台接单的订单数量和订单总时长，本步骤中，根据接送乘客数据和订单数据，确定出目标签约车辆的非本平台接单的订单数量；根据状态数据和上下线数据，确定目标签约车辆的非本平台接单的订单总时长，得到非本平台接单数据。
74.示例性地，分别对各目标签约车辆的接送乘客数据进行分析和统计，确定各目标签约车辆的第一订单数量，分别对各目标签约车辆的订单数据进行分析和统计，确定第二订单数量，将各目标签约车辆的第一订单数量与第二订单数量做差，得到各目标签约车辆的非本平台接单的订单数量。
75.示例性地，分别对各目标签约车辆的状态数据进行分析和统计，确定各目标签约车辆上监控设备处于开机状态的时长，即各目标签约车辆的行驶时长，分别对各目标签约车辆的上下线数据进行分析和统计，确定驾驶各目标签约车辆的司机登录司机端app的时长，即各目标签约车辆的上线时长，将各目标签约车辆的行驶时长与上线时长作差，得到各目标签约车辆的非本平台接单的订单总时长。
76.在另一种可能的实施方式中，非本平台接单数据包括非本平台接单的订单数量、订单总时长和订单时间分布，本步骤中，根据订单数据和上下线数据，确定目标签约车辆反馈的有乘客行驶的第一有客时间段、无乘客行驶的第一无客时间段和未上线时间段；根据接送乘客数据和状态数据，确定目标签约车辆实际的有乘客行驶的第二有客时间段、无乘客行驶的第二无客时间段和未工作时间段；根据第一有客时间段、第二有客时间段、第一无
客时间段、第二无客时间段、未上线时间段和未工作时间段，确定目标签约车辆的非本平台接单的订单数量、订单总时长和订单时间分布，得到非本平台接单数据。
77.其中，有客时间段，是指车辆处于行驶状态且车上有乘客的一个或多个时间段；无客时间段，是指车辆处于行驶状态但车上没有乘客的一个或多个时间段；未上线时间段，是指驾驶车辆的司机未登录司机端app的一个或多个时间段；未工作时间段，是指车辆处于熄火的一个或多个时间段，即监控设备处于关机状态的一个或多个时间段。
78.示例性地，若根据某签约车辆的上下线数据和订单数据，确定司机在8：00-10：00为上线状态，10：00-11：00为下线状态，并且8：00-10：00之间有一笔订单，该订单起始时间为8：10，结束时间为9：00，则可以确定该车辆在8：00-11：00之间的第一有客时间段是8：10-9：00，第一无客时间段为8：00-8：10和9：00-10：00，未上线时间段为10：00-11：00。
79.在得到第一有客时间段、第一无客时间段、未上线时间段、第二有客时间段、第二无客时间段和未工作时间段之后，通过统计和分析，得到目标签约车辆的非本平台接单的订单数量、订单总时长和订单时间分布。
80.可选地，通过将由反馈数据分析得到的时间段与由监控数据分析得到的时间段分别标记在两条时间轴上，并对齐两条时间轴，通过简单的比较，就可以得到订单数量、订单总时长和订单时间分布。
81.示例性地，图4为本技术实施例一提供的一种确定非本平台接单数据的逻辑示意图，如图4所示，通过将第一有客时间段、第一无客时间段、未上线时间段标记在时间轴a上，将第二有客时间段、第二无客时间段和未工作时间段标记在时间轴b上，图4中用白色区间表示有客时间段，黑色区间表示无客时间段，带有斜线的区间表示未上线时间段(a轴)或未工作时间段(b轴)，司机端app反馈了5笔订单，分别用y1、y2、y3、y4和y5表示，监控系统监控到了8笔订单，分别用x1、x2、x3、x4、x5、x6、x7和x8表示。
82.通过比对a轴和b轴上的数据不难看出，该签约车辆的非本平台接单的订单数量为3笔，分别为x4、x6和x7，订单总时长为x4、x6和x7三笔订单的时间之和，订单时间分布可以根据订单x4、x6和x7的起始时间和终止时间确定。
83.本实施例中，通过获取签约车辆的在目标时间段内订单数据和上下线数据，根据签约车辆的订单数据和上下线数据，确定出疑似接非本平台订单的目标签约车辆，获取目标签约车辆在目标时间段内的监控数据，根据目标签约车辆的订单数据、上下线数据和监控数据，确定目标签约车辆的非本平台接单数据。不仅可以识别出接非本平台订单的目标签约车辆，还可以识别出目标签约车辆的接非本平台订单的订单数量、总时长和时间段等，实现了对签约车辆非本平台接单行为的量化，有利于网约车平台制定出更加合理和具有针对性的管理策略，从而实现网约车平台对签约车辆的精细化管理，进而达到减少签约车辆的非本平台接单行为和减少网约车平台损失的目的。
84.实施例二
85.下面将一个具体的实施例对本技术的技术方案做进一步说明，以每日全面排查的场景为例，本实施例通过两个部分，实现签约车辆的非本平台接单数据的确定：
86.(一)找出疑似接非本平台订单的目标签约车辆，方案如下：
87.1.1统计t-1日网约车平台的所有签约车辆的日订单数和日在线总时长，并按照城市进行汇总，计算出不同城市的人均日在线总时长和人均订单数；
88.1.2先纵向对比，将每个签约车辆的日在线总时长和日订单数与签约司机所在城市的人均日在线总时长和人均订单数分别对比，例如，设定一个系数阈值，将低于城市均值水平*系数阈值的签约车辆，确定为异常签约车辆；
89.1.3再横向对比，将异常签约车辆的t-1日期内的工作时间按照预设时长(如30分钟)进行切片，根据上下线记录，确定异常签约车辆的工作时间中是否存在未上线的时段或者上线时长未满30分钟的异常时段，若存在，则将异常签约车辆确定为疑似接非本平台订单的目标签约车辆。
90.(二)通过车辆监控的数据，计算出目标签约车辆接非本平台接的时长和订单量
91.2.1网约车平台根据每个目标签约车辆在t-1日的订单记录，则统计各目标签约车辆订单数量(即系统订单数)、订单时间分布和订单时长，再根据每个目标签约车辆在t-1日的上下线记录日志，计算出各目标签约车辆的日在线总时长；
92.2.2网约车平台为保障司机和乘客的安全，一般车内都有监控，如果监控识别出车内除了司机外还有其他乘客的话，则认为该司机在接送乘客，则统计接送乘客次数(即监控订单数)、时间分布和时长；
93.2.3将监控系统统计出的数据和平台系统内部的订单数据做比较，则算出“有乘客无订单”的时间分布、时长以及订单数。非本平台的订单数则为监控订单数与系统订单数的差值；非本平台的在线时长可以通过先求监控系统有乘客行驶时间与无乘客行驶时间的和，得到监控系统的开机工作时长，再通过求监控系统的开机工作时长与平台系统记录的日在线总时长的差值得到；非本平台的订单时间分布可以根据监控系统比平台系统多出的订单的时间确定。
94.本技术实施例利用网约车平台的监控数据和平台系统的订单信息及司机的上下线记录，就能判别出签约司机是否同时接多个网约车平台的订单，不需要依赖其他网约车平台的数据，具有较强的可实施性。
95.可以理解的是，本实施例仅作为一种举例，在一些实施例中，也可以根据签约车辆的实时监控和网约车平台的实时订单数据，实时监控哪些司机出现了“有订单无乘客”的情况或者提前预测出哪些司机可能想要接其他平台的订单，从而采取不同的措施，如对这部分司机进行派单倾斜，满足其日常的接单需求，以防止其流失或减少平台损失等。
96.实施例三
97.图5为本技术实施例三提供的一种网约车监管装置的结构示意图，该装置可以由软件和硬件的方式来实现，并可集成于服务器中。如图5所示，本实施例中网约车监管装置10包括：
98.获取模块11和处理模块12。
99.获取模块11，用于获取签约车辆的在目标时间段内订单数据和上下线数据；
100.处理模块12，用于根据签约车辆的订单数据和上下线数据，确定出疑似接非本平台订单的目标签约车辆；
101.获取模块11，还用于获取目标签约车辆在目标时间段内的监控数据；
102.处理模块12，还用于根据目标签约车辆的订单数据、上下线数据和监控数据，确定目标签约车辆的非本平台接单数据。
103.可选地，处理模块12具体用于：
104.根据监控数据，确定目标签约车辆在目标时间段内的接送乘客数据和目标签约车辆上监控设备的状态数据；
105.根据目标签约车辆的订单数据、上下线数据、接送乘客数据和状态数据，确定目标签约车辆的非本平台接单数据。
106.可选地，非本平台接单数据包括非本平台接单的订单数量和订单总时长；处理模块12具体用于：
107.根据接送乘客数据和订单数据，确定出目标签约车辆的非本平台接单的订单数量；
108.根据状态数据和上下线数据，确定目标签约车辆的非本平台接单的订单总时长。
109.可选地，非本平台接单数据包括非本平台接单的订单数量、订单总时长和订单时间分布；处理模块12具体用于：
110.根据订单数据和上下线数据，确定目标签约车辆反馈的有乘客行驶的第一有客时间段、无乘客行驶的第一无客时间段和未上线时间段；
111.根据接送乘客数据和状态数据，确定目标签约车辆实际的有乘客行驶的第二有客时间段、无乘客行驶的第二无客时间段和未工作时间段；
112.根据第一有客时间段、第二有客时间段、第一无客时间段、第二无客时间段、未上线时间段和未工作时间段，确定目标签约车辆的非本平台接单的订单数量、订单总时长和订单时间分布。
113.可选地，处理模块12具体用于：
114.对各签约车辆的订单数据和上下线数据分别进行统计，确定出各签约车辆的日订单数、日在线总时长和未上线时段；
115.根据各签约车辆的日订单数、日在线总时长和未上线时段，通过条件筛选，确定出目标签约车辆。
116.可选地，处理模块12具体用于：
117.将各签约车辆的日订单数与订单数指标以及日在线总时长与在线时长指标作比较，并将日订单数低于订单数指标且日在线总时长低于在线时长指标的签约车辆，确定为候选签约车辆；
118.确定各候选签约车辆的未上线时段中是否存在异常时段，并将存在异常时段的候选签约车辆确定为目标签约车辆，异常时段为连续未上线时长超过预设时长的时段。
119.可选地，处理模块12还用于：
120.确定各签约车辆所在城市的人均日订单数和人均日在线总时长；
121.根据人均日订单数和第一订单系数，确定各签约车辆的订单数指标；
122.根据人均日在线总时长和第一时长系数，确定各签约车辆的在线时长指标。
123.可选地，处理模块12还用于：
124.确定各签约车辆的历史日均订单数和历史日均在线总时长；
125.根据历史日均订单数和第二订单系数，确定各签约车辆的订单数指标；
126.根据历史日均在线总时长和第二时长系数，确定各签约车辆的在线时长指标。
127.本实施例所提供的网约车监管装置可执行上述方法实施例所提供的网约车监管方法，具备执行方法相应的功能模块和有益效果。本实施例的实现原理和技术效果与上述
方法实施例类似，此处不再一一赘述。
128.实施例四
129.图6为本技术实施例四提供的一种服务器的结构示意图，如图6所示，该服务器20包括存储器21、处理器22及存储在存储器上并可在处理器上运行的计算机程序；服务器20中处理器22的数量可以是一个或多个，图6中以一个处理器22为例；服务器20中的处理器22、存储器21可以通过总线或其他方式连接，图6中以通过总线连接为例。
130.存储器21作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本技术实施例中的获取模块11和处理模块12对应的程序指令/模块。处理器22通过运行存储在存储器21中的软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述的网约车监管方法。
131.存储器21可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器21可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器21可进一步包括相对于处理器22远程设置的存储器，这些远程存储器可以通过网格连接至服务器。上述网格的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
132.实施例五
133.本技术实施例五还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在由计算机处理器执行时用于执行一种网约车监管方法，该方法包括：
134.获取签约车辆的在目标时间段内订单数据和上下线数据；
135.根据签约车辆的订单数据和上下线数据，确定出疑似接非本平台订单的目标签约车辆；
136.获取目标签约车辆在目标时间段内的监控数据；
137.根据目标签约车辆的订单数据、上下线数据和监控数据，确定目标签约车辆的非本平台接单数据。
138.当然，本技术实施例所提供的一种包计算机可读存储介质，其计算机程序不限于如上所述的方法操作，还可以执行本技术任意实施例所提供的网约车监管方法中的相关操作。
139.通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本技术可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、闪存(flash)、硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网格设备等)执行本技术各个实施例所述的方法。
140.值得注意的是，上述网约车监管装置的实施例中，所包括的各个单元和模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，各功能单元的具体名称也只是为了便于相互区分，并不用于限制本技术的保护范围。
141.注意，上述仅为本技术的较佳实施例及所运用技术原理。本领域技术人员会理解，
本技术不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本技术的保护范围。因此，虽然通过以上实施例对本技术进行了较为详细的说明，但是本技术不仅仅限于以上实施例，在不脱离本技术构思的情况下，还可以包括更多其他等效实施例，而本技术的范围由所附的权利要求范围决定。