订单处理方法、装置、服务器及计算机存储介质与流程

本公开的实施例涉及互联网技术领域，尤其涉及一种订单处理方法、装置、服务器及存储介质。

背景技术：

随着互联网技术的不断发展，越来越多的平台开始进驻网约业务，例如，网约车、外卖以及跑腿服务等，同时，接单人员也可以承接多个平台的网约业务。

目前，同一接单人员在单个订单进程中，还可以在其他平台承接其他订单，以获得更多的利益。但是，这种现象在导致当前订单的时效性下降，用户体验较差的同时，还会造成当前订单所在平台的损失。

因此，亟需一种订单处理方法，以准确识别同一接单人员在单个订单进程中，在其他平台承接其他订单的现象。

技术实现要素：

本公开的实施例提供一种订单处理方法、装置、服务器及存储介质，用以解决现有技术中，无法准确识别同一接单人员在单个订单进程中，在其他平台承接其他订单的现象。

一方面，本公开的实施例提供一种订单处理方法，包括：

获取接单人员的终端设备发送的终端设备中的第一信息，第一信息用于指示终端设备中使用的应用程序；

若根据第一信息确定接单人员为目标人员，则获取接单人员接单的候选订单的行驶时空轨迹，其中，目标人员表示终端设备中使用的应用程序与目标应用程序的业务相关的接单人员，候选订单为接单人员通过终端设备中的目标应用程序接单的订单；

根据行驶时空轨迹，确定候选订单的一个或多个停驻点；

根据确定的一个或多个停驻点，确定候选订单是否为目标订单，其中，目标订单表示目标人员在使用目标应用程序进行候选订单的过程中还进行其他应用程序中的订单。

可选的，根据行驶时空轨迹，确定候选订单的一个或多个停驻点，包括：

根据行驶时空轨迹和时空轨迹聚类算法，确定行驶时空轨迹中涉及的停驻点；

从确定的行驶时空轨迹中涉及的停驻点中排除候选订单的起点和终点，以获得候选订单的一个或多个停驻点。

可选的，根据候选订单进行的时段、天气中的至少一项确定时空轨迹聚类算法中的参数。

可选的，时空轨迹聚类算法包括：st-dbscan算法。

可选的，根据确定的一个或多个停驻点，确定候选订单是否为目标订单，包括：

若停驻点的数量大于预设数量，则确定候选订单为目标订单。

可选的，获取接单人员接单的候选订单的行驶时空轨迹，包括：

获取接单人员的候选订单的订单数据，订单数据包括如下至少一项：预估行驶里程、实际行驶里程、预估行驶时间及实际行驶时间；

根据订单数据确定候选订单的绕路指数，绕路指数指示接单人员的绕路程度；

若根据绕路指数，确定候选订单为疑似目标订单，则获取接单人员接单的候选订单的行驶时空轨迹。

可选的，根据订单数据确定候选订单的绕路指数，包括：

根据实际行驶里程与预估行驶里程，确定里程绕路指数，和/或，

根据实际行驶时间与预估行驶时间，确定时间绕路指数。

可选的，里程绕路指数为实际行驶里程与预估行驶里程的比值，时间绕路指数为实际行驶时间与预估行驶时间的比值；

根据绕路指数，确定候选订单为疑似目标订单，包括：

若里程绕路指数大于预设里程绕路指数，和/或，时间绕路指数大于预设时间绕路指数，则确定候选订单为疑似目标订单。

可选的，预设里程绕路指数和/或预设时间绕路指数的大小与预估行驶里程的大小有关。

可选的，订单数据还包括如下至少一项：服务时段、行驶路径的区域、服务车型；

根据绕路指数，确定候选订单为疑似目标订单，包括：

根据绕路指数、订单数据和候选订单对应的行驶区域的限行规则，确定不符合限行规则的候选订单为疑似目标订单；

其中，限行规则包括以下至少一种：限行时段、限行车辆类型以及限行区域。

可选的，该方法还包括：若根据确定的一个或多个停驻点，确定候选订单为目标订单，则输出提示消息，提示消息用于提示候选订单为目标订单。

可选的，提示消息中还包括候选订单的行程录音和/或照片，提示消息还用于提示候选订单需人工审查。

第二方面，本公开的实施例提供一种订单处理装置，包括：

获取单元，用于获取接单人员的终端设备发送的终端设备中的第一信息，第一信息用于指示终端设备中使用的应用程序；

处理单元，用于若根据第一信息确定接单人员为目标人员，则获取接单人员接单的候选订单的行驶时空轨迹，其中，目标人员表示终端设备中使用的应用程序与目标应用程序的业务相关的接单人员，候选订单为接单人员通过终端设备中的目标应用程序接单的订单；

确定单元，用于根据行驶时空轨迹，确定候选订单的一个或多个停驻点，以及根据确定的一个或多个停驻点，确定候选订单是否为目标订单，其中，目标订单表示目标人员在使用目标应用程序进行候选订单的过程中还进行其他应用程序中的订单。

可选的，确定单元具体用于：根据行驶时空轨迹和时空轨迹聚类算法，确定行驶时空轨迹中涉及的停驻点；

从确定的行驶时空轨迹中涉及的停驻点中排除候选订单的起点和终点，以获得候选订单的一个或多个停驻点。

可选的，根据候选订单进行的时段、天气中的至少一项确定时空轨迹聚类算法中的参数。

可选的，时空轨迹聚类算法包括：st-dbscan算法。

可选的，确定单元具体用于：若停驻点的数量大于预设数量，则确定候选订单为目标订单。

可选的，处理单元具体用于：获取接单人员的候选订单的订单数据，订单数据包括如下至少一项：预估行驶里程、实际行驶里程、预估行驶时间及实际行驶时间；

根据订单数据确定候选订单的绕路指数，绕路指数指示接单人员的绕路程度；

若根据绕路指数，确定候选订单为疑似目标订单，则获取接单人员接单的候选订单的行驶时空轨迹。

可选的，确定单元具体用于：根据实际行驶里程与预估行驶里程，确定里程绕路指数，和/或，

根据实际行驶时间与预估行驶时间，确定时间绕路指数。

可选的，里程绕路指数为实际行驶里程与预估行驶里程的比值，时间绕路指数为实际行驶时间与预估行驶时间的比值；

确定单元具体用于：

若里程绕路指数大于预设里程绕路指数，和/或，时间绕路指数大于预设时间绕路指数，则确定候选订单为疑似目标订单。

可选的，预设里程绕路指数和/或预设时间绕路指数的大小与预估行驶里程的大小有关。

可选的，订单数据还包括如下至少一项：服务时段、行驶路径的区域、服务车型；

确定单元具体用于：

根据绕路指数、订单数据和候选订单对应的行驶区域的限行规则，确定不符合限行规则的候选订单为疑似目标订单；

其中，限行规则包括以下至少一种：限行时段、限行车辆类型以及限行区域。

可选的，订单处理装置还包括：输出单元，用于若根据确定的一个或多个停驻点，确定候选订单为目标订单，则输出提示消息，提示消息用于提示候选订单为目标订单。

可选的，提示消息包括以下至少一种：候选订单的音频、视频以及图像记录。

第三方面，本公开的实施例提供一种服务器，包括：

存储器和处理器；

存储器用于存储程序指令；

处理器用于调用存储器中的程序指令执行如第一方面任一项的方法。

第四方面，本公开的实施例提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序；计算机程序被执行时，实现如第一方面任一项的方法。

本公开的实施例提供一种订单处理方法、装置、服务器及计算机存储介质，该方法包括：获取接单人员的终端设备发送的终端设备中的第一信息，若根据所述第一信息确定所述接单人员为目标人员，则获取所述接单人员接单的候选订单的行驶时空轨迹，再根据行驶时空轨迹，确定候选订单的一个或多个停驻点，最后根据确定的一个或多个停驻点，确定候选订单是否为目标订单。通过接单人员的终端设备中第一信息即可确定目标人员，再通过目标人员的候选订单的停驻点确定目标订单，从而准确识别同一接单人员在单个订单行程中，在其他平台的应用程序中承接其他订单的现象，以降低当前平台端的损失。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1为本公开一实施例提供的订单处理的场景示例图；

图2为本公开一实施例提供的订单处理方法的流程示意图；

图3为本公开另一实施例提供的订单处理方法的流程示意图；

图4为本公开一实施例提供的订单管理系统的架构示意图；

图5为本公开一实施例提供的订单处理方法的子流程的流程示意图；

图6为本公开一实施例提供的利用停驻点识别模型识别停驻点的流程示意图；

图7为本公开一实施例提供的停驻点识别模型训练方法的流程图；

图8为本公开一实施例提供的订单处理装置的结构示意图；

图9为本公开另一实施例提供的订单处理装置的结构示意图；

图10为本公开一实施例提供的服务器的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

网约服务为用户的日常生活提供了便利，网约服务是指基于移动互联网、以手机app为主要服务平台、为具有服务需求的顾客和具有服务资格与能力的接单人员提供信息沟通和有保障连接服务的新型商业运行模式。网约服务包括：外卖服务、跑腿服务以及网约车服务，其中，网约车可以包括客运网约车以及货运网约车等。是传统服务业的补充。随着互联网技术的不断发展，越来越多的平台开始进驻网约业务，同时，接单人员也可以承接多个平台的网约业务。

现有技术中，由于同一接单人员可以在多个平台进行接单，因此，在单个订单行程中，会出现同时在其他平台承接其他订单的情况，以获得更多的利益。以网约车为例，同一司机在第一平台接单后，在订单进行过程中，还可以在第二平台进行接单，从而在订单进程中途绕路去完成第二平台的订单。这种现象在导致当前订单的时效性下降，用户体验较差的同时，还会造成当前平台端的损失。

基于上述问题，本公开实施例提供一种订单处理方法、装置、服务器及计算机存储介质，通过接单人员的终端设备上的应用程序信息确定目标人员，根据订单的基础数据确定疑似目标订单，结合停驻点识别等多维指标，识别接单人员在订单进程中取送其他平台订单的目标订单的行为，从而降低当前平台的损失。

为方便理解，首先结合图1对本公开实施例的场景进行说明，需要说明的是，本方案适用于多种场景，例如：外卖场景、跑腿服务场景以及网约车服务场景，本公开使用的场景不做特别限定，为方便理解，本实施例以网约车场景为例进行说明。

图1为本公开的实施例提供的订单处理的场景示例图，如图1所示，该场景包括：网约车101、服务器102、终端设备103、终端设备104、接单人员及平台管理人员。

其中，网约车101可以为能够通过终端设备103与服务器102通信连接的任意车辆，包括但不限于货运车、载客车，图1的网约车101以载客车为例示出。

终端设备104上运行着网约车平台的服务端应用程序，管理人员可以通过终端设备104对网约车平台进行相应管理。终端设备103上运行网约车平台的接单人员端应用程序。当客户在客户端发布订单后，接单人员可以使用终端设备103在网约车平台接单人员端应用程序上接单。

终端设备103和终端设备104可以为能够与服务器102通信连接的任意设备，包括但不限于：智能手机、台式电脑、便携式电脑、平板电脑、掌上电脑、可穿戴设备、虚拟现实设备、增强现实设备等或其任何组合，在此不做限定。其中，图1以终端设备103以智能手机为例示出，终端设备104以台式电脑示出。终端设备103和终端设备104均可以通过无线或有线网络与服务器102通信。无线网络可以是2g或者3g或者4g或者5g等通信网络，也可以是无线局域网，在此不做限定。

在实际应用中，服务器102可以获取接单人员的终端设备103中的订单数据。一方面，订单数据对应的订单可以为一段时间内，利用该终端设备103接单的所有订单。另一方面，订单数据对应的订单也可以是一段时间内通过该服务器102接单的所有订单，对此本公开不做特别限定。

进一步的，服务器102通过订单数据确定该订单是否为目标订单，当确定该订单是目标订单后，通过终端设备104输出提示消息给平台管理人员，由平台管理人员进一步确定该订单是否为目标订单，其中，对于输出提示信息的方式，本公开不做特别限定，例如向终端设备104展示上述提示消息。

下面以具体地实施例对本公开的实施例的技术方案以及本公开的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。

图2为本公开一实施例提供的订单处理方法的流程示意图。本公开实施例的执行主体可以为网约车订单处理装置，具体的，该装置可以以软件或硬件的方式设置于图1所示的服务器中。如图2所示，本公开实施例的方法，包括如下步骤：

s201、获取接单人员的终端设备发送的终端设备中的第一信息。

其中，第一信息用于指示终端设备中使用的应用程序。

可以理解的是，对于应用程序的类型，本公开不做特别限定。一方面，可以是安装在终端设备中的应用软件，另一方面，也可以是终端设备中所使用的小程序。

在实际应用中，采集接单人员的终端设备中的软件日志，其中，该软件日志是由接单人员的终端设备发送至服务器的，软件日志包括：应用软件使用日志和/或小程序使用日志。具体的，软件日志包括以下至少一种字段：接单人员标识、应用程序列表以及各字段的更新时间。

进一步的，对软件日志中的应用程序列表信息进行扫描，获取其它应用软件的安装信息和/或其它小程序的使用信息，其中，应用软件的安装信息用于指示终端设备中安装的应用软件，小程序的使用信息用于指示接单人员在终端设备中使用的小程序的信息。可以理解的是，接单人员可以利用其它应用软件和/或其它小程序进行网约车接单业务。

s202、若根据第一信息确定接单人员为目标人员，则获取接单人员接单的候选订单的行驶时空轨迹。

其中，目标人员表示终端设备中使用的应用程序与目标应用程序的业务相关的接单人员，候选订单为接单人员通过终端设备中的目标应用程序接单的订单；

可以理解的是，根据接单人员标识以及其它应用软件和/或其它小程序之间的对应关系，确定终端设备中安装有其它应用软件和/或其它小程序的接单人员标识，从而确定目标人员。

进一步的，当确定目标人员之后，获取目标人员通过目标应用程序接单的候选订单，其中，目标应用程序为本公开的服务器上运行的网约车软件。然后，获取接单人员接单的候选订单的行驶时空轨迹。

需要说明的是，获取接单人员接单的候选订单的行驶时空轨迹的方法有多种，本实施例对此不做具体限定。一种可选的实施方式中，获取候选订单中，时间与经纬度的对应关系，根据时间以及经纬度的对应关系确定该候选订单对应的行驶时空轨迹。示例性的，时空轨迹的数据形式可以表达为{(lat1，lon1，t1)，(lat2，lon2，t2)，...，(latn，lonn，tn)}。其中(latn，lonn，tn)代表t时间，候选订单所在的经度和纬度为(latn，lonn)。

s203、根据行驶时空轨迹，确定候选订单的一个或多个停驻点。

在实际应用中，根据行驶时空轨迹，确定候选订单的停驻点的方法有多种，本实施例对此也不做具体限定。在一种实施方式中，可以通过在同一经纬度的停留时间确定停驻点，示例性的，在(lat1，lon1)处，其停留时间超过预设时间，则确定该经纬度对应的点为一个停驻点，可以理解的是，预设时间可以根据该订单的车速等因素确定，本实施例对此不做特别限定，示例性的，预设时间为10秒。即，当在同一经纬度点的停留时间大于等于10秒时，确定该经纬度点为停驻点。

在另一种实施方式中，还可以通过在某一经纬度的车辆速度来确定停驻点，示例性的，在(lat1，lon1)处，车辆速度小于预设速度，则确定该经纬度对应的点为一个停驻点，可以理解的是，预设速度可以根据实际需求进行设定，本实施例对此不做特别限定，示例性的，预设速度为0km/h，即当在(lat1，lon1)处，车辆速度为0时，确定该经纬度点为停驻点。

s204、根据确定的一个或多个停驻点，确定候选订单是否为目标订单。

其中，目标订单表示目标人员在进行候选订单的过程中还进行其它应用程序中的订单。

在实际应用中，可以根据候选订单的停驻点数量确定候选订单是否为目标订单。

本公开的实施例提供的订单处理方法，获取接单人员的终端设备发送的终端设备中的第一信息，若根据所述第一信息确定所述接单人员为目标人员，则获取所述接单人员接单的候选订单的行驶时空轨迹，再根据行驶时空轨迹，确定候选订单的一个或多个停驻点，最后根据确定的一个或多个停驻点，确定候选订单是否为目标订单。通过接单人员的终端设备中安装的应用程序安装信息确定目标人员，再通过目标人员的候选订单的停驻点确定目标订单，从而准确识别同一接单人员在单个订单行程中，在其他平台的应用程序中承接其他订单的现象，以降低当前平台端的损失。

图3为本公开另一实施例提供的订单处理方法的流程示意图。在上述实施例的基础上，本实施例对本公开技术方案进行更详细的描述，如图3所示，本实施例提供的方法，可以包括：

s301、获取来自接单人员的终端设备的第一信息。

需要说明的是，本实施例提供的步骤s301与图2所示实施例中的步骤s201类似，其方法和原理类似，此处不再赘述。

s302、若根据第一信息确定接单人员为目标人员，则获取接单人员接单的候选订单。

其中，候选订单为接单人员通过终端设备中的目标应用程序接单。

s303、若候选订单为疑似目标订单，则获取候选订单的行驶时空轨迹。

下面结合具体步骤s3031～s3036对步骤s303行具体说明。

s3031、根据订单数据确定候选订单的绕路指数。

其中，绕路指数指示接单人员的绕路程度。

在实际应用中，订单数据可以包括如下至少一项：预估行驶里程、实际行驶里程、预估行驶时间及实际行驶时间。

需要说明的是，在获取订单数据之后，由于数据底层表往往包括大量冗余信息，需要通过数据预处理，以减少数据冗余，提高运行效率。

其中，数据预处理可以包括以下至少一种：数据清洗、数据筛选以及数据降维等。

具体的，绕路指数可以包括：里程绕路指数以及时间绕路指数。

在实际应用中，根据订单数据确定候选订单的绕路指数可以包括：根据实际行驶里程与预估行驶里程，确定里程绕路指数，和/或，

根据实际行驶时间与预估行驶时间，确定时间绕路指数。

具体的，里程绕路指数为实际行驶里程与预估行驶里程的比值，时间绕路指数为实际行驶时间与预估行驶时间的比值。

可以理解的是，里程绕路指数以及时间绕路指数可以有多种计算方法，本实施例对此不做特别限定。在一种可能的实施方式中，里程绕路指数可以为实际行驶里程比预估行驶里程的比值。在另一种可能的实施方式中，里程绕路指数也可以为预估行驶里程实际比行驶里程的比值。相应的，时间绕路指数与里程绕路指数的计算方法类似，在此不再赘述。

s3032、根据绕路指数，确定候选订单为疑似目标订单。

具体的，若里程绕路指数大于预设里程绕路指数，和/或，时间绕路指数大于预设时间绕路指数，则确定候选订单为疑似目标订单。

需要说明的是，在判断候选订单是否为疑似目标订单时，有多种判断方法，对此本实施例不做具体限制。在一种实施方式中，为了满足不同的场景需求，可以利用里程绕路指数或者时间绕路指数中的其中一项，确定候选订单是否为疑似目标订单，示例性的，在一些场景中，候选订单所在的网约车平台不支持其中一项数据的统计时，例如，一些平台只能记录订单里程，此时，只需要根据历程绕路指数即可确定是否为疑似目标订单。通过本公开实施例提供的方法，可以适应多种场景。

在另一种实施方式中，为了保证疑似目标订单识别的准确性，需要里程绕路比和时间绕路比同时满足预设要求。示例性的，在一些场景中，订单的里程超过预设里程，但是该订单的实际行驶时间并没有超过该订单的预估行驶时间，此时可能不存在接单其它平台订单的行为，因此，需要在里程绕路指数大于预设里程绕路指数的同时，时间绕路指数大于预设时间绕路指数，此时，才能确定该候选订单为疑似目标订单。

可以理解的是，本实施例中的预设时间绕路指数和预设里程绕路指数可以根据实际需求进行设定，本实施例对此不做特别限定。在一种实施方式中，预设时间绕路指数和预设里程绕路指数均为固定值，对值得大小不做特别限定，例如，预设时间绕路指数和预设里程绕路指数均为3。

在另一种实施方式中，预设里程绕路指数和/或预设时间绕路指数的大小与预估行驶里程的大小有关。可以理解的是，在一些订单中，若订单的预估行驶里程较小，接单人员遇到拥堵等情况可能导致预设里程绕路指数和/或预设时间绕路指数的很容易被满足，从而造成疑似目标订单的误识别，此时可以适当调节预设里程绕路指数和/或预设时间绕路指数。以提升疑似目标订单识别的准确性。以里程绕路指数为实际行驶里程比预估行驶里程的比值，预设里程绕路指数大小为3为例，当预估行驶里程的距离小于预设值时，提高预设里程绕路指数，预设里程绕路指数的提高幅度根据实际需求进行设定，本实施例均不以此为限定，示例性的，将预设历程绕路指数调整为4。

在一些实施例中，订单数据还包括如下至少一项：服务时段、行驶路径的区域、服务车型。

在实际应用中，候选订单所在区域的行驶规则也会对订单造成一些影响，因此，可以根据行驶规则进一步判断候选订单是否为疑似坐标订单，以提高疑似目标订单的准确性。下面结合具体步骤进行具体说明。

s3033、根据绕路指数、订单数据和候选订单对应的行驶区域的限行规则判断候选订单是否符合限行规则。

s3034、若是，则确定候选订单不是疑似目标订单，结束订单处理流程。

其中，限行规则包括以下至少一种：限行时段、限行车辆类型以及限行区域。

可以理解的是，疑似目标订单的订单数据应不符合限行规则。

在实际应用中，当确定候选订单存在绕路行为之后，获取该候选订单的订单数据中的服务路径所在的区域。

若候选订单服务路径所在的区域慢速限行规则中的限行区域，则继续获取候选订单的服务时段以及服务车型。

进一步的，确定该候选订单的服务时段以及服务车型是否满足该限行区域的限行规则。若订单服务时段包括了限行时段，且订单预估行驶路径在限行区域内，则暂不将该订单认作疑似目标订单。

示例性的，候选订单所在的服务区域为杭州某一区域，订单开始时间为17：00，结束时间为17：30，服务车型为货车，而杭州该区域的限行规则为：16：00～20：00，限制货车通行。接单人员为避开限行路段，从绕城高速行驶到目的地，此时，即使订单满足里程绕路指数大于预设里程绕路指数，和/或，时间绕路指数比大于预设时间绕路指数，该候选订单亦不作为疑似目标订单。

通过本实施例提供的方法，可以根据各区域的限行规则确定疑似目标订单，将不符合限行规则的候选订单确定为疑似目标订单，从而提升疑似目标订单识别的准确性，避免误伤正常接单的接单人员，造成接单人员的损失。

s3035、若否，则确定候选订单为疑似目标订单，获取候选订单的行驶时空轨迹。

可以理解的是，获取候选订单的时空轨迹的方法与图2所示实施例种的步骤s202类似，此处不再赘述。

s304、根据行驶时空轨迹，确定候选订单的一个或多个停驻点。

s305、根据确定的一个或多个停驻点，确定候选订单是否为目标订单。

s306、若是，则输出提示消息。

其中，提示消息用于提示候选订单为目标订单。提示消息包括以下至少一种：候选订单的音频、视频以及图像记录。

进一步的，对目标订单进行最终审查，根据候选订单的音频、视频以及图像记录确定是否在接单目标订单时接单其它平台订单。可以理解的是，对于最终审查的方法，本公开不做特别限定。一方面，可以又人工进行审查，具体的，输出提示消息至网约车平台的管理人员，由管理人员对候选订单进行人工审查，本公开对输出提示消息的方法不做具体限制，示例性的，可以向管理人员的终端设备发送提示消息。另一方面，也可以由服务器自动审核，根据候选订单的音频、视频以及图像记录确定是否在接单目标订单时接单其它平台订单。本公开对于审核方式也不做具体限定，示例性的，通过智能语义识别和/或图像识别等方式，识别提示消息中的候选订单的音频、视频以及图像记录中是否有取送其他订单的行为的相关信息，若存在，则确定在接单目标订单时接单其它平台订单。

在一种实施方式中，当确定在接单目标订单时接单其它平台订单时，可以根据目标订单制定相应的惩罚措施，具体的，可以根据目标订单的绕路指数来确定惩罚措施，示例性的，绕路指数越高，则惩罚越重。

在另一种实施方式中，当确定候选订单为目标订单时，也可以由管理人员确定惩罚措施，服务器接收该惩罚措施，根据该惩罚措施对该接单人员进行相应的惩罚。

通过本方案，可以制定相应的惩罚措施，当同一接单人员在单个订单行程中，在其他平台承接其他订单时，利用该惩罚措施对该接单人员实施相应的惩罚，以降低当前平台端的损失。

s307、若否，则结束订单处理流程。

本公开实施例提供一种订单处理方法，获取接单人员的终端设备发送的终端设备中的第一信息，若根据第一信息确定接单人员为目标人员，则获取接单人员接单的候选订单，再根据订单数据确定候选订单的绕路指数，若根据绕路指数，确定候选订单为疑似目标订单，则获取接单人员接单的候选订单的行驶时空轨迹，通过绕路指数确定候选订单为疑似目标订单，可以准确的识别疑似目标订单，从而判断出同一接单人员在单个订单行程中，在其他平台承接其他订单的现象，以降低当前平台端的损失。另外，本公开的实施例中，通过预估订单里程以及限行规则，进一步识别疑似目标订单，可以进一步提升疑似目标订单识别的准确性，避免误伤接单人员，从而造成接单人员的损失。

在实际应用中，本公开实施例的执行主体可以为网约车订单的处理装置，具体的，该装置中安装有订单管理系统，为方便理解，下面结合图4对本公开提供的订单管理系统的架构及原理进行详细说明。

图4为本公开一实施例提供的订单管理系统的架构示意图。如图4所示，首先，从数据库中获取算法所需要的订单基础表、软件日志采集表、订单心跳数据表对应字段数据，可以理解的是，该数据库为网约车平台的订单数据库。

其中，订单基础表中所需字段包括以下至少一种数据：订单标识、接单人员标识、订单起点经度、订单起点纬度、订单终点经度、订单终点纬度、订单预估行驶里程、订单实际行驶里程、订单预估行驶时间、订单实际行驶时间、数据更新时间等。

软件日志采集表包括以下至少一种数据：接单人员标识、应用程序列表、小程序列表以及字段更新时间等。

订单心跳数据表中所需字段包括以下至少一种数据：订单标识、接单人员标识、经度、纬度、数据更新时间等。

进一步的，对获取的数据表进行数据预处理，包括但不限于去除表中的重复数据、空值数据、异常数据等，选取算法所需要字段。

由于数据底层表往往包括大量冗余信息，通过本实施例提供的方案，可以减少数据冗余，提高算法运行效率。

一方面，对应用程序列表以及小程序列表进行扫描，可以从中筛选出安装了其它应用软件以及终端设备中有其它小程序的接单人员。示例性的，接单人员集{d1，d2，d3}中d2，d3接单人员安装了其他网约车平台的应用软件，则将{d2，d3}标记为目标人员。

另一方面，进行绕路指数计算，根据预设绕路指数确定疑似目标订单。其中，计算绕路指数的方案与图3所示实施例的方案类似，对此不再赘述。

示例性的，以预设里程绕路指数、预设时间绕路指数为3，订单集

{o1，o2，o3}分别为接单人员集{d1，d2，d3}对应的订单为例，若订单o1，o2满足里程绕路指数>3，和/或，时间绕路指数>3，则{o1，o2}为疑似目标订单。

可以理解的是，上述获取目标人员和获取疑似目标订单的顺序，本公开实施例对此不做限定。

进一步的，获得了疑似目标订单集{o1，o2}和目标人员集{d2，d3}，进行相互匹配，获得目标人员{d2}产生的疑似目标订单{o2}，即获得疑似多平台接单行为的目标订单{o2}，作为停驻点识别模型中的订单数据输入，获取目标订单。

可以理解的是，利用停驻点识别模型获取目标订单的方案与图3所示实施例中的原理及有益效果类似，此处不再赘述。

在一种实施方式中，在获取目标订单之后，需要人工进行再次审查。具体的，可以通过导出这部分订单，再通过货物照片、行程录音听音等方式，进行人工审查。

图5为本公开一实施例提供的订单处理方法的子流程的流程示意图。在上述实施例的基础上，本实施例对本公开技术方案中确定候选订单为目标订单的方案进行更详细的描述，如图5所示，本实施例提供的方法，包括如下步骤：

s401、获取接单人员接单的候选订单的行驶时空轨迹。

可以理解的是，本实施例中步骤s401的方案及原理与图2所示实施例中的步骤s202类似，具体可参考图2所示的实施例，本实施例对此不再赘述。

s402、根据行驶时空轨迹和时空轨迹聚类算法，确定行驶时空轨迹中涉及的停驻点。

具体的，将行驶时空轨迹作为时空轨迹聚类算法的输入，利用时空轨迹聚类算法识别该行驶时空轨迹中涉及的停驻点。

在一种实施方式中，该时空轨迹聚类算法可以为st-dbscan算法。

s403、确定行驶时空轨迹中涉及的停驻点中是否存在起点和终点。

在实际应用中，在订单进行过程中，会有一些正常停驻点，例如，订单的起点、终点，以及行驶过程中的正常途径点。为了防止正常停驻点带来的干扰，需要判断行驶时空轨迹中是否存在正常停驻点，以防止对正常订单的误判。

s404、若是，则从确定的行驶时空轨迹中涉及的停驻点中排除候选订单的起点和终点，以获得候选订单的一个或多个停驻点。

具体的，根据订单数据确定正常停驻点的经纬度坐标，根据正常停驻点的经纬度坐标确定正常停驻点对应的行驶时空轨迹中涉及的停驻点。

进一步的，删除正常停驻点对应的行驶时空轨迹中涉及的停驻点，以获得候选订单的一个或多个停驻点。

通过本实施例，可以排除候选订单中正常停驻点，以防止正常停驻点对识别疑似目标订单造成的干扰。

s405、若否，则确定行驶时空轨迹中涉及的停驻点为候选订单的一个或多个停驻点。

可以理解的是，若行驶时空轨迹中涉及的停驻点中不存在正常停驻点，即证明行驶时空轨迹中涉及的停驻点均未被误判，此时，输出行驶时空轨迹中涉及的停驻点为候选订单的一个或多个停驻点。

在一些实施例中，除了上述方法，还可以利用停驻点识别模型来识别候选订单中的一个或多个停驻点。下面结合图6对停驻点识别模型识别停驻点的方案及原理进行具体说明。

图6为本公开一实施例提供的利用停驻点识别模型识别停驻点的流程示意图。其中，该停驻点识别模型是根据时空轨迹聚类算法训练得到的。如图6所示，在获得候选订单的行驶时空轨迹之后，将候选订单的行驶时空轨迹作为该模型中的st-dbscan算法的输入，输出候选订单中的高密度停驻点。

在实际应用中，st-dbscan算法在计算过程中涉及许多参数，如eps1、eps2、min_samples等参数，分别代表聚类的空间密度阈值、时间阈值和高密度点的数据点数量要求。

通过调节上述参数，可以在时空轨迹聚类算法中排除红绿灯等排队等候聚集点的干扰，获得时空高密度的停驻点n′＝{n1，n2，n3，...nm}。

可以理解的是，可以根据候选订单进行的时段、天气中的至少一项确定时空轨迹聚类算法中的参数。

进一步的，停驻点中排除订单本身起点、终点和途径点，即排除是正常等待乘客导致的停留。对比获得的停驻点集n′＝{n1，n2，n3，…nm}和起点、终点和途径点经纬度，若为同一地点，则将其删除，获得新的停驻点集n＝{n1，n2，n3，...nl}。

在一些实施例中，在获得候选订单的一个或多个停驻点之后，还需要对停驻点进行验证，以准确获得由于在进行候选订单中，还进行其他订单时所产生的停驻点。下面结合步骤s406～s409进行具体说明。

s406、验证停驻点是否准确。

具体的，验证该停驻点是否是在接单人员在进行候选订单中，还进行其他订单时所产生的停驻点。

需要说明的是，可以通过多种方法对停驻点进行验证，本实施例对此不做特别限定。一方面，可以查看该订单的行驶时空轨迹，具体的，获取停驻点的坐标，判断该坐标是否为红绿灯等交通要点的坐标位置，若是，则该停驻点为正常停驻点。若否，则确定该停驻点通过验证，即该停驻点是由于在进行候选订单中，还进行其他订单时所产生的停驻点。另一方面，获取候选订单的交通情况，其中，交通情况可以包括：拥堵路段的坐标以及拥堵路段的拥堵时间，从而判断停驻点是否因拥堵而造成，若是，则为正常停驻点。类似的，若否，则确定该停驻点通过验证，即该停驻点是由于在进行候选订单中，还进行其他订单时所产生的停驻点。其他方面，还可以根据候选订单的停驻点的形成录音来判断该停驻点是否为正常停驻点，具体的，获取停驻点对应的时间点的行程录音，根据录音判断当前停驻点是否为正常停驻点。

s407、若是，则确定候选订单的一个或多个停驻点通过验证，判断停驻点的数量是否大于预设数量。

可以理解的是，预设数量可以根据实际需求确定，本实施例对比不做具体限定。例如，预设数量为1个。

s408、若否，则确定候选订单的一个或多个停驻点未通过验证，调节时空轨迹聚类算法的参数，以输出调节参数后的时空轨迹聚类算法。

可以理解的是，可以根据候选订单进行的时段、天气中的至少一项确定时空轨迹聚类算法中的参数。

s409、若停驻点的数量大于预设数量，则确定候选订单为目标订单。

示例性的，以预设数量为1为例，当候选订单的行驶时空轨迹中的停驻点的数量大于等于1时，即说明该候选订单为目标订单。

若停驻点的数量不大于预设数量，则确定候选订单不是目标订单，结束流程。

在实际应用中，时空轨迹聚类算法在计算过程中涉及许多参数，如st-dbscan算法中有eps1、eps2、min_samples等参数，分别代表聚类的空间密度阈值、时间阈值和高密度点的数据点数量要求。

当候选订单的一个或多个停驻点未通过验证时，即说明本次获取候选订单中的停驻点的算法不够精确，需要调节时空轨迹聚类算法的参数，以迭代优化算法，从而提高停驻点识别的准确性。

在其他场景中，时空轨迹聚类算法中的参数与候选订单进行的时段、天气中的至少一项有关。不同的时段、天气运用相同的参数会导致停驻点不准确，因此，需要根据候选订单进行的时段、天气中的至少一项来调节参数，以获得更准确的停驻点。

可以理解的是，本实施例对调节参数的方法不做特别限定。在一种实施方式中，可以给时空轨迹聚类算法中每个参数设置多组不同的取值，不同的取值对应于不同的天气情况或时间段，在利用时空轨迹聚类算法计算停驻点时，只需要获取当前订单的天气情况或时间段，即可确定天气情况或时间段所对应的参数。然后，根据参数即可获取当前订单的时空行驶轨迹中的停驻点。

可以理解的是，在一种实施方式中，可以利用调节参数后的时空轨迹聚类算法对本次订单处理的订单进行重新处理，以获得当前订单处理过程的准确结果。在另一种实施方式中，也可以利用调节参数后的时空轨迹聚类算法进行下一次订单处理，以实现算法的迭代优化，不断优化本公开的订单处理方法。

本实施例提供的方法，通过对利用算法的到的停驻点进行验证，调节算法参数，从而不断地进行迭代优化算法，可以提高停驻点识别的准确性。

在一种可选的方案中，对应于图6所述的停驻点识别模型，当利用驻点识别模型获得的候选订单的停驻点未通过验证时，可以对上述停驻点识别模型进行训练，以优化该停驻点识别模型。下面结合图7对本公开实施例提供的停驻点识别模型训练方法及原理进行详细说明。

图7为本公开一实施例提供的停驻点识别模型训练方法的流程图。如图7所示，若上一步骤发现利用停驻点识别模型识别停驻点的准确性较低，即候选订单的停驻点未通过验证，则需要进行参数调节，提高停驻点识别模型的准确性；若识别准确率较高，即候选订单的停驻点通过验证，则可不作调节。

可以理解的是，对于进行参数调节以优化停驻点识别模型的方案，本公开实施例不做特别限定。一方面，考虑到每笔订单的情况不同，可在不同天气情况、时间段等选用不同参数，如在雨天高峰期加强阈值限定，增大eps1、eps2、min_samples参数。可以理解的是，参数的调节方法与图6所示实施例提供的方法类似，此处不再赘述。

进一步的，在一种实施方式中，可以利用调节参数后的停驻点识别模型对本次订单处理的订单进行重新处理，以获得当前订单处理过程的准确结果。在另一种实施方式中，也可以利用调节参数后的停驻点识别模型进行下一次订单处理，以实现停驻点识别模型的迭代优化，不断优化本公开的订单处理方法。

本公开实施例提供一种订单处理方法，获取接单人员接单的候选订单的行驶时空轨迹，根据行驶时空轨迹和时空轨迹聚类算法，确定行驶时空轨迹中涉及的停驻点，从确定的行驶时空轨迹中涉及的停驻点中排除候选订单的起点和终点，以获得候选订单的一个或多个停驻点，若停驻点的数量大于预设数量，则确定候选订单为目标订单，输出提示消息。通过本实施例，可以根据停驻点准确的识别目标订单，从而提示平台管理人员进行相应的处理，以降低当前平台端的损失。另外，本公开的实施例中，通过对利用算法的到的停驻点进行验证，调节算法参数，从而不断地进行迭代优化算法，从而可以提高本公开停驻点识别的准确性。

图8为本公开一实施例提供的订单处理装置的结构示意图。如图8所示，该订单处理装置500包括：获取单元501、处理单元502、确定单元503。

其中，获取单元501，用于获取接单人员的终端设备发送的终端设备中的第一信息，第一信息用于指示所述终端设备中使用的应用程序；

处理单元502，用于若根据第一信息确定接单人员为目标人员，则获取接单人员接单的候选订单的行驶时空轨迹，其中，所述目标人员表示终端设备中使用的应用程序与目标应用程序的业务相关的接单人员，候选订单为所述接单人员通过终端设备中的目标应用程序接单的订单；

确定单元503，用于根据行驶时空轨迹，确定候选订单的一个或多个停驻点，以及根据确定的一个或多个停驻点，确定候选订单是否为目标订单，其中，目标订单表示目标人员在进行候选订单的过程中还进行其它应用程序中的订单。

可以理解的是，本实施例所提供的订单处理装置，可用于执行如上述任一方法实施例的技术方案，其实现原理和技术效果类似，具体可参考上述方法实施例，此处不再赘述。

图9为本公开另一实施例提供的订单处理装置的结构示意图。如图9所示，该订单处理装置500还包括：输出单元504。

可选的，确定单元503具体用于：根据行驶时空轨迹和时空轨迹聚类算法，确定行驶时空轨迹中涉及的停驻点；

从确定的行驶时空轨迹中涉及的停驻点中排除候选订单的起点和终点，以获得候选订单的一个或多个停驻点。

可选的，根据候选订单进行的时段、天气中的至少一项确定时空轨迹聚类算法中的参数。

可选的，时空轨迹聚类算法包括：st-dbscan算法。

可选的，确定单元503具体用于：若停驻点的数量大于预设数量，则确定候选订单为目标订单。

可选的，处理单元502具体用于：获取接单人员的候选订单的订单数据，订单数据包括如下至少一项：预估行驶里程、实际行驶里程、预估行驶时间及实际行驶时间；

根据订单数据确定候选订单的绕路指数，绕路指数指示接单人员的绕路程度；

若根据绕路指数，确定候选订单为疑似目标订单，则获取接单人员接单的候选订单的行驶时空轨迹。

可选的，确定单元503具体用于：根据实际行驶里程与预估行驶里程，确定里程绕路指数，和/或，

根据实际行驶时间与预估行驶时间，确定时间绕路指数。

可选的，里程绕路指数为实际行驶里程与预估行驶里程的比值，时间绕路指数为实际行驶时间与预估行驶时间的比值；

确定单元503具体用于：

若里程绕路指数大于预设里程绕路指数，和/或，时间绕路指数大于预设时间绕路指数，则确定候选订单为疑似目标订单。

可选的，预设里程绕路指数和/或预设时间绕路指数的大小与预估行驶里程的大小有关。

可选的，订单数据还包括如下至少一项：服务时段、行驶路径的区域、服务车型；

确定单元503具体用于：

根据绕路指数、订单数据和候选订单对应的行驶区域的限行规则，确定不符合限行规则的候选订单为疑似目标订单；

其中，限行规则包括以下至少一种：限行时段、限行车辆类型以及限行区域。

可选的，输出单元504，用于若根据确定的一个或多个停驻点，确定候选订单为目标订单，则输出提示消息，提示消息用于提示候选订单为目标订单。

可选的，提示消息包括以下至少一种：候选订单的音频、视频以及图像记录。

可以理解的是，本实施例所提供的订单处理装置，可用于执行如上述任一方法实施例的技术方案，其实现原理和技术效果类似，具体可参考上述方法实施例，此处不再赘述。

图10为本公开一实施例提供的服务器的结构示意图。图10所示，本公开实施例的服务器700可用于实现上述方法实施例中描述的方法，具体参见上述方法实施例中的说明。

服务器700包括处理组件701，其进一步包括一个或多个处理器，以及由存储器702所代表的存储器资源，用于存储可由处理组件701的执行的指令，例如应用程序。存储器702中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件701被配置为执行指令，以执行如图2、图3、图4所示的方法实施例，具体参见上述方法实施例中的说明，此处不再赘述。

服务器700还可以包括一个有线或无线网络接口703被配置为将服务器700连接到网络，和一个输入输出(i/o)接口704。服务器700可以操作基于存储在存储器702的操作系统，例如windowsservertm，macosxtm，unixtm,linuxtm，freebsdtm或类似。

本领域技术人员可以理解的是，图10中示出的服务器的结构并不构成对本服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

在此需要说明的是，本公开提供的上述服务器，用于实现上述方法实施例中描述的方法，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

本公开实施例还提供一种非临时性计算机可读存储介质，当该存储介质中的指令由终端设备的处理器执行时，使得共享车辆和/或服务器能够执行上述方法实施例中的订单处理方法。

在本公开所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本公开各个实施例所述方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(英文：read-onlymemory，简称：rom)、随机存取存储器(英文：randomaccessmemory，简称：ram)、磁碟或者光盘等各种可以存储程序代码的介质。

在上述网络设备或者终端设备的实施例中，应理解，处理器可以是中央处理单元(英文：centralprocessingunit，简称：cpu)，还可以是其他通用处理器、数字信号处理器(英文：digitalsignalprocessor，简称：dsp)、专用集成电路(英文：applicationspecificintegratedcircuit，简称：asic)等。结合本公开所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

最后应说明的是，本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开的实施例旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求书指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求书来限制。