CN111179004A - 数据处理方法、装置、服务器、司机终端及存储介质 - Google Patents

Abstract

本申请涉及一种数据处理方法、装置、服务器、司机终端及存储介质，属于互联网技术领域。该方法应用于网约打车的服务器，该方法包括：获取当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据；基于所述接单数据确定所述多个司机终端的排列顺序；根据所述排列顺序和预设规则确定每个所述司机终端的预期的账户变更数据；将每个所述司机终端对应的排列顺序和预期的账户变更数据分别发送给对应的司机终端。该方法通过让司机可以实时了解自己在活动内的排列顺序情况和预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

Description

数据处理方法、装置、服务器、司机终端及存储介质

技术领域

本申请属于互联网技术领域，具体涉及一种数据处理方法、装置、服务器、司机终端及存储介质。

背景技术

随着互联网和智能终端技术的发展，人们经常使用手机并通过打车软件来满足自己方便出行的需求。乘客在使用打车软件过程中，只需要设置出发地、目的地、支付方式等基本信息，就可以满足最基本的出行需要.

目前高峰期(例如，上下班)打车供需严重失调，很多上班族因为打不到车而无法按时上班或回家，从而造成体验感不好。因此，如何保证稳定的运力变得十分重要。

发明内容

鉴于此，本申请的目的在于提供一种数据处理方法、装置、服务器、司机终端及存储介质，以有效地改善上述问题。

本申请的实施例是这样实现的：

第一方面，本申请实施例提供了一种数据处理方法，应用于网约打车的服务器，所述方法包括：获取当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据；基于所述接单数据确定所述多个司机终端的排列顺序；根据所述排列顺序和预设规则确定每个所述司机终端的预期的账户变更数据；将每个所述司机终端对应的排列顺序和预期的账户变更数据分别发送给对应的司机终端。本申请实施例中，通过获取一时间段内的多个司机终端的接单数据来确定各个司机终端的排列顺序情况，然后基于该排列顺序情况和预设规则确定各个司机终端的预期的账户变更数据，并将对应的排列顺序和预期的账户变更数据发送给对应的司机终端，以使司机可以实时了解自己在活动内的排列顺序情况和预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

结合第一方面的一种可选实施方式，所述基于所述接单数据确定所述多个司机终端的排列顺序，包括：根据预设排序规则和所述接单数据确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格；对所述多个司机终端中有排序资格的司机终端按照流水大小进行排序，得到各自的排列顺序。本申请实施例中，在对各个司机终端进行排序时，通过确定各自是否有资格进行排序，即只对有排序资格的司机终端进行排序，通过提高准入门槛，从而在保证运力稳定的前提下，可以降低补贴成本。

结合第一方面的又一种可选实施方式，所述根据预设排序规则和所述接单数据确定所述多个司机终端的每个司机终端是否有按照流水大小进行排序的资格，包括：根据所述接单数据判断所述多个司机终端中的每个司机终端在所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意一个或任意组合是否不小于对应的预设阈值来确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格。

结合第一方面的又一种可选实施方式，所述方法还包括：在所述当前时间点为预设结束时间点时，判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；在所述多个司机终端中存在可以获得对应的预期的账户变更数据的第一司机终端时，向所述第一司机终端发放对应的预期的账户变更数据。本申请实施例中，在活动结束时，判断各个司机终端是否可以获得对应的预期的账户变更数据，对可以获得对应的预期的账户变更数据的司机终端对应的预期的账户变更数据，以提高司机的热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

结合第一方面的又一种可选实施方式，所述判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据，包括：通过判断所述多个司机终端中的每个司机终端是否存在作弊行为来确定所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；其中，不存在作弊行为的司机终端可以获得对应的预期的账户变更数据。本申请实施例中，通过判断各个司机终端是否存在作弊行为来减少损失，杜绝司机为了获取预期的账户变更数据而作弊。

第二方面，本申请实施例还提供了一种数据处理方法，应用于网约打车的客户端，所述方法包括：接收查看请求；从服务器获取所述服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据确定的排列顺序以及预期的账户变更数据；对所述排列顺序和所述预期的账户变更数据进行显示。本申请实施例中，司机通过客户端可以实时查看自己在活动中的名次以及预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

第三方面，本申请实施例还提供了一种数据处理装置，应用于网约打车的服务器，所述装置包括：获取模块、第一确定模块、第二确定模块以及发送模块；获取模块，用于获取当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据；第一确定模块，用于基于所述接单数据确定所述多个司机终端的排列顺序；第二确定模块，用于根据所述排列顺序和预设规则确定每个所述司机终端的预期的账户变更数据；发送模块，用于将每个所述司机终端对应的排列顺序和预期的账户变更数据分别发送给对应的司机终端。本申请实施例中，通过获取一时间段内的多个司机终端的接单数据来确定各个司机终端的排列顺序情况，然后基于该排列顺序情况和预设规则确定各个司机终端的预期的账户变更数据，并将对应的排列顺序和预期的账户变更数据发送给对应的司机终端，以使司机可以实时了解自己在活动内的名次和预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

结合第三方面的一种可选实施方式，所述第一确定模块，还用于根据预设排序规则和所述接单数据确定所述多个司机终端的每个司机终端是否有按照流水大小进行排序的资格；以及还用于对所述多个司机终端中有排序资格的司机终端按照流水大小进行排序，得到各自的排列顺序。本申请实施例中，在对各个司机终端进行排序时，通过确定各自是否有资格进行排序，即只对有排序资格的司机终端进行排序，通过提高准入排序门槛，从而在保证运力稳定的前提下，可以降低补贴成本。

结合第三方面的又一种可选实施方式，所述第一确定模块还用于根据所述接单数据判断所述多个司机终端中的每个司机终端在所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意一个或任意组合是否不小于对应的预设阈值来确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格。

结合第三方面的又一种可选实施方式，所述装置还包括：判断模块以及发放模块；判断模块，用于在所述当前时间点为预设结束时间点时，判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；发放模块，用于在所述多个司机终端中存在可以获得对应的预期的账户变更数据的第一司机终端时，向所述第一司机终端发放对应的预期的账户变更数据。本申请实施例中，在活动结束时，判断各个司机终端是否可以获得对应的预期的账户变更数据，对可以获得对应的预期的账户变更数据的司机终端对应的预期的账户变更数据，以提高司机的热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

结合第三方面的又一种可选实施方式，所述判断模块，还用于通过判断所述多个司机终端中的每个司机终端是否不存在作弊行为来确定所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；其中，不存在作弊行为的司机终端可以获得对应的预期的账户变更数据。本申请实施例中，通过判断各个司机终端是否存在作弊行为来减少损失，杜绝司机为了获取预期的账户变更数据而作弊的行为发生。

第四方面，本申请实施例还提供了一种数据处理装置，应用于网约打车的客户端，所述装置包括：接收模块、获取模块以及显示模块；接收模块，用于接收查看请求；获取模块，用于从服务器获取所述服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据确定的排列顺序以及预期的账户变更数据；显示模块，用于对所述排列顺序和所述预期的账户变更数据进行显示。本申请实施例中，司机通过客户端可以实时查看自己的名次以及预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

第五方面，本申请实施例还提供了一种服务器，包括：存储器和处理器，所述存储器和所述处理器连接；所述存储器用于存储程序；所述处理器用于调用存储于所述存储器中的程序，以执行上述第一方面或第一方面中的任意一种可选的实施方式提供的方法。

第六方面，本申请实施例还提供了一种司机终端，包括：存储器和处理器，所述存储器和所述处理器连接；所述存储器用于存储程序；所述处理器用于调用存储于所述存储器中的程序，以执行上述第二方面提供的方法。

第七方面，本申请实施例还提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述第一方面或第一方面中的任意一种可选的实施方式提供的方法。

第八方面，本申请实施例还提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述第二方面提供的方法。

本申请的其他特征和优点将在随后的说明书阐述，并且，部分地从说明书中变得显而易见，或者通过实施本申请实施例而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。通过附图所示，本申请的上述及其它目的、特征和优势将更加清晰。在全部附图中相同的附图标记指示相同的部分。并未刻意按实际尺寸等比例缩放绘制附图，重点在于示出本申请的主旨。

图1示出了本申请实施例提供的一种派单系统的交互示意图。

图2示出了本申请实施例提供的一种服务器的结构示意图。

图3示出了本申请实施例提供的一种应用于服务器的数据处理方法的流程图。

图4示出了本申请实施例提供的一种应用于客户端的数据处理方法的流程图。

图5示出了本申请实施例提供的一种应用于服务器的数据处理装置的模块示意图。

图6示出了本申请实施例提供的一种应用于客户端的数据处理装置的模块示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

在本申请的描述中，需要说明的是，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。再者，本申请中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

第一实施例

请参阅图1，图1为本申请实施例提供的一种派单系统100的交互示意图。该派单系统100包括：乘车终端10、司机终端30和服务器20，乘车终端10通过网络与服务器20进行数据交互，司机终端30通过网络与服务器20进行数据交互。本实施例中，乘车终端10、司机终端30的数量为至少一个，其中，乘车终端10以及司机终端30中安装有至少一个应用程序(Application，APP)与服务器20进行数据交互，以便服务器20接收乘车终端10发送的用车订单，然后为该乘车终端10分派合适的司机终端30，并将订单分配给该司机终端30。

其中，该司机终端30可以为司机的手机、平板电脑或司机车辆内安装的车载设备等移动终端，而该乘车终端10可以为乘客的手机、平板电脑等移动终端。其中，司机终端30包括：存储器和处理器，所述存储器和所述处理器连接；所述存储器用于存储程序；所述处理器用于调用存储于所述存储器中的程序，以执行第三实施例所述的方法。其中，司机终端30的结构示意图可以参阅服务器20的结构示意图。

如图2所示，服务器20可以为网络服务器、数据库服务器或由多个子服务器构成的服务器集群。服务器20通过分别与司机终端30和乘车终端10进行数据交互，可以执行并实现涉及数据处理方法。

可选地，服务器20可以包括：存储器21、通信模块22、总线23和处理器24。其中，处理器24、通信模块22和存储器21通过总线23连接。处理器24用于执行存储器21中存储的可执行模块，例如计算机程序。图2所示的服务器20的组件和结构只是示例性的，而非限制性的，根据需要，服务器20也可以具有其他组件和结构。

其中，存储器21可能包含高速随机存取存储器(Random Access Memory RAM)，也可能还包括非不稳定的存储器(non－volatile memory)，例如至少一个磁盘存储器。本实施例中，存储器21存储了处理器24执行数据处理方法所需要的程序。

总线23可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图2中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

处理器24可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器24中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器24可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。

本申请实施例任意实施例揭示的流过程或定义的装置所执行的方法可以应用于处理器24中，或者由处理器24实现。处理器24在接收到执行指令后，通过总线23调用存储在存储器21中的程序后，处理器24通过总线23控制通信模块22则可以执行数据处理方法的流程。

第二实施例

请参阅图3，为本申请实施例提供的一种应用于上述服务器20的数据处理方法，下面将结合图3对其所包含的步骤进行说明。

步骤S101：获取当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据。

获取当前时间点至预设起始时间点这一时间段内的多个司机终端的接单数据。其中，需要说明是，预设起始时间点早于当前时间点。预设起始时间点根据实际需要来设定，例如在计算周排名时，该预设起始时间点可以是的一周的开始点，例如周天至周一的交界点，即零点零分零秒；当然也可以是指定某一个时间为起始点，例如指定周三的中午12点为起始点，到下周的周三中午12点即为一周。又例如在计算月排名时，该预设起始时间点可以是的一月的开始点，例如上月末至本月初的交界点，即零点零分零秒；当然也可以是指定某一个时间为起始点，例如指定上月的某天中午12点为起始点，到下月的该天中午12点即为一月。其余情形与之类似，在此不再举例说明，例如计算10天排名、15天排名、20天排名、3个月排名、半年排名等的情况的与之类似。

其中，需要说明的是，上述的示例仅仅是为了便于理解而举的例子而已，不能将其理解成是对本申请的限制。

步骤S102：基于所述接单数据确定所述多个司机终端的排列顺序。

在获取到当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据后，基于获取到的接单数据确定所述多个司机终端中的每个司机终端当前的排列顺序，例如，基于获取到的接单数据对多个司机终端按照流水大小进行排序，得到各自的排列顺序。例如获取了1000个司机终端各自的接单数据，根据获取的这1000个司机终端各自的接单数据来确定各个司机终端的排列顺序。其中，需要说明的是，在对各个司机终端进行排序时，可以是对报名参加活动(活动需司机终端自主选择参加)的所有司机终端进行排序，得到各自的排列顺序；若活动无需司机终端自主选择参加，如默认参加时，可以是获取所有注册的司机终端进行排序，得到各自的排列顺序。

作为一种可选的实施方式，可以是根据预设排序规则和所述接单数据确定所述多个司机终端的每个司机终端是否有按照流水大小进行排序的资格；然后对所述多个司机终端中有排序资格的司机终端按照流水大小进行排序，得到各自的排列顺序。例如，根据预设排序规则和获取的1000个司机终端各自的接单数据来确定这1000个司机终端中的每个司机终端是否有按照流水大小进行排序的资格；假设这1000个司机终端中有500个司机终端有排序资格，则对有排序资格的这500个司机终端按照流水大小进行排序，得到这500个司机终端中的每个司机终端的排列顺序情况。

其中，上述的预设排序规则为事先设定的排排序规则，可以是满足该预设排序规则的司机终端有资格进行排序，也可以是不满足该预设排序规则的司机终端有资格进行排序，在此不作进一步限定，至于是何种方式，其主要取决于预设排序规则。

作为一种可选的实施方式，所述根据预设排序规则和所述接单数据确定所述多个司机终端的每个司机终端是否有按照流水大小进行排序的资格，包括：根据所述接单数据判断所述多个司机终端中的每个司机终端在所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意一个和/或任意组合是否不小于对应的预设阈值来确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格。

其中，确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格时，可以是根据所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意一个是否不小于对应的预设阈值来确定各个司机终端是否有按照流水大小进行排序的资格，例如，以流水为例，判断多个(例如1000个)司机终端中的每个司机终端的周流水(包括顺路单和预约单)是否不小于第一阈值(例如，2100元)，若小于第一阈值，如小于2100元，则没有资格进行流水排序，这类司机终端不纳入进行排序的队列中。又例如，以订单数为例，判断多个(例如1000个)司机终端中的每个司机终端的周订单数是否不小于第二阈值(例如，50单)，若小于第二阈值，如小于50单，则没有资格进行流水排序，这类司机终端不纳入进行排序的队列中。又例如，以成单率为例，判断多个(例如1000个)司机终端中的每个司机终端的周成单率是否不小于第三阈值(例如，85％)，若小于第三阈值，如小于85％，则没有资格进行流水排序，这类司机终端不纳入进行排序的队列中。又例如，以服务分为例，判断多个(例如1000个)司机终端中的每个司机终端的在活动周期结束时服务分是否不小于第四阈值(例如，80分)，若小于第四阈值，如小于80分，则没有资格进行流水排序，这类司机终端不纳入进行排序的队列中。又例如，以星级为例，判断多个(例如1000个)司机终端中的每个司机终端在活动周期结束时的星级是否不小于第五阈值(例如，4.5)，若小于第五阈值，如小于4.5，则没有资格进行流水排序，这类司机终端不纳入进行排序的队列中。

其中，确定所述多个司机终端中的每个司机终端是否有资格进行流水排序时，可以是根据所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意组合是否不小于对应的预设阈值来确定各个司机终端是否有进行流水排序的资格。为了便于理解下面以同时满足这5个条件的情况为例，进行说明：

判断多个(例如1000个)司机终端中的每个司机终端的周流水是否不小于第一阈值(例如，2100元)，若小于第一阈值，如小于2100元，则没有资格进行流水排序，这类司机终端不纳入进行排序的队列中。假设这1000个司机终端中有800个司机终端有进行流水排序的资格，即这800个司机终端的周流水不小于第一阈值，如不小于2100元。

判断周流水不小于第一阈值的司机终端(假设有800个)的订单数是否有不小于第二阈值(例如，50单)，若小于第二阈值，如小于50单，则没有进行流水排序的资格，这类司机终端不纳入进行排序的队列中。假设这800个司机终端中有700个司机终端有进行流水排序的资格，即这700个司机终端的周订单数不小于第二阈值，如不小于50单。

判断周订单数不小于第二阈值的司机终端(假设有700个)的周成单率是否有不小于第三阈值(例如，85％)，若小于第三阈值，如小于85％，则没有进行流水排序的资格，这类司机终端不纳入进行排序的队列中。假设这700个司机终端中有650个司机终端有进行流水排序的资格，即这650个司机终端的周成单率不小于第三阈值，如不小于85％。

判断周成单率不小于第三阈值的司机终端(假设有650个)在活动周期结束时的服务分是否有不小于第四阈值(例如，80分)，若小于第四阈值，如小于80分，则没有进行流水排序的资格，这类司机终端不纳入进行排序的队列中。假设这650个司机终端中有600个司机终端有进行流水排序的资格，即这600个司机终端的服务分不小于第四阈值，如不小于80分。

判断服务分不小于第四阈值的司机终端(假设有600个)在活动周期结束时的星级是否有不小于第五阈值(例如，4.5分)，若小于第五阈值，如小于4.5分，则没有进行流水排序的资格，这类司机终端不纳入进行排序的队列中。假设这600个司机终端中有500个司机终端有进行流水排序的资格，即这500个司机终端的服务分不小于第五阈值，如不小于4.5分。

其中，需要说明的是，通过流水、订单数、成单率、服务分、星级等条件判断各个司机终端是否有进行流水排序的资格，来提高准入条件，可以进一步降低补贴的成本。

其中，需要说明的是，在基于流水、订单数、成单率、服务分、星级等条件判断各个司机终端是否有进行流水排序的资格时，执行步骤没有先后之分，例如，以这5个条件来筛选有流水排序的司机终端时，并不一定要按照上述的顺序，即先流水、再订单数、再成单率、再服务分、最后再星级的顺序执行，而是可以以任意的顺序执行，因此，不能将上述的示例理解成是对本申请的限制。

其中，需要说明的是，上述的示例的1000、800、700、650、600、500等仅仅是为了便于理解而举的例子而已，不能将其理解成是对本申请的限制。同理，上述的各个阈值(如第一阈值、第二阈值、第三阈值、第四阈值、第五阈值)的示例也不能将其理解成是对本申请的限制，具体数值应根据实际需要来设定，且不同的活动周期(例如一周、一月)，数值也不一样。

步骤S103：根据所述排列顺序和预设规则确定所述每个司机终端的预期的账户变更数据。

在得到各个司机终端当前的排列顺序排列顺序后，基于该排列顺序排列顺序和预设规则确定所述每个司机终端的预期的账户变更数据。即，根据各个司机终端当前的排列顺序和预设规则确定各个司机终端的预期的账户变更数据。例如，排名前10％(包含10％)，奖励3300元；排名前10％(不包含10％)至50％(包含50％)，奖励2200元；排名前50％(不包含50％)至90％(包含90％)，奖励1300元；排名前90％(不包含90％)至150％(包含150％)，奖励700元；排名前150％(不包含150％)至200％(包含200％)，奖励300元等。

其中，该账户变更数据可以用表示钱、币、券、积分等的数字数据。

其中，需要说明的是，上述示例的预设规则进行是为了便于理解而举的例子而已，其可以根据实际需要设置，不能将其理解成对本申请的限制。

步骤S104：将每个所述司机终端对应的排列顺序和预期的账户变更数据分别发送给对应的司机终端。

在得到各个司机终端的对应的排列顺序和预期的账户变更数据后，将各自的排列顺序和预期的账户变更数据分别发送给对应的司机终端，以使司机可以实时了解自己在活动内的排名情况和预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

司机除了可以看见自己的排列顺序和预期的账户变更数据外，还可以看见要获得预期的账户变更数据所需满足的条件(即获奖条件)、奖励规则以及注意事项。以便司机实时知悉在哪些方面还不满足条件，从而可以定向的去完成任务，例如，接单数不满足情况，可以多接单，以保证在周期结束时，达到要求。

其中，获奖条件，例如周期内流水不小于2100元；周期内订单数不小于50单；周期内平均指派成单率不小于85％；周期结束时服务分不小于80分；周期结束时星级不小于4.5分。

其中，奖励规则，例如排名前10％(包含10％)，奖励3300元；排名前10％(不包含10％)至50％(包含50％)，奖励2200元；排名前50％(不包含50％)至90％(包含90％)，奖励1300元；排名前90％(不包含90％)至150％(包含150％)，奖励700元；排名前150％(不包含150％)至200％(包含200％)，奖励300元等。

其中，注意事项，例如，1.奖励会在本周起结束后24小时内统一发放；2.流水奖励包括基础车费、调度费、空驶补偿费和动调费；3.活动期间，有任何作弊行为，将被淘汰，所获奖励会被取消等事项。

作为另一种可选的实施方式，所述方法还包括：在所述当前时间点为预设结束时间点时，判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；在所述多个司机终端中存在可以获得对应的预期的账户变更数据的第一司机终端时，向所述第一司机终端发放对应的预期的账户变更数据。也就是说，在到达预设的活动结束时间时，判断各个司机终端是否可以获得对应的预期的账户变更数据，对可以获取对应的预期的账户变更数据的司机终端发放其奖励。通过判断各个司机终端是否存在作弊行为来减少损失，杜绝司机为了获取预期的账户变更数据而作弊，从而降低补贴成本，营造良好的网约车环境。

其中，作为一种可选的实施方式，判断各个司机终端是否可以获得对应的预期的账户变更数据时，可以是判断其是否到达可以获得预期的账户变更数据的获奖条件来判断，例如周期内流水不小于2100元；周期内订单数不小于50单；周期内平均指派成单率不小于85％；周期结束时服务分不小于80分；周期结束时星级不小于4.5分。其中，需要说明的是，通过该方式来判断是否可以获得对应的预期的账户变更数据时，在确定各自的排列顺序时，可以不判断是否有进行按照流水大小进行排序的资格，以避免采用相同的判断条件重复判断。

其中，作为一种可选的实施方式，可以是通过判断所述多个司机终端中的每个司机终端是否存在作弊行为来确定所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；其中，不存在作弊行为的司机终端可以获得对应的预期的账户变更数据。

其中，在进行作弊行为判定时，若在一周期内，同一个用户打到同一个司机终端的次数大于预设值时，则可以判定该司机终端存在作弊行为，例如，用户A在一个星期内，连续3次打车对应的司机均为司机终端A，则判定司机终端A存在作弊行为。其中，需要说明的是，上述的示例3仅仅是为了便于理解而举的例子，其预设值应根据实际需要设定。

其中，在进行作弊行为判定时，若打车用户打车所使用的手机号码对应的注册身份证与司机终端注册时的身份证相同，也就是说，司机用不同的手机号码(与司机终端使用的手机号不同)打车，然后自己接单，即可判定为存在作弊行为。

其中，在发放奖励时，可以是将其对应的预期的账户变更数据直接下发至对应的司机终端的账户，也可以是下发至司机终端在注册时所预留的账户，例如银行卡账户。在此不作进一步限定。

第三实施例

本申请实施例还提供了一种应用于网约打车的客户端的数据处理方法，如图4所示。下面将结合图4所示的步骤对其进行说明。

步骤S201：接收查看请求。

司机接入客户端后，点击活动页，即司机发送查看请求，此时客户端接收该司机发起的查看请求。

步骤S202：从服务器获取所述服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据确定的排列顺序以及预期的账户变更数据。

客户端在接收到查看请求后，基于该查看请求从服务器获取排列顺序以及预期的账户变更数据。其中，该排列顺序和预期的账户变更数据是服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据而确定的。其中，服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据确定排列顺序和预期的账户变更数据的过程请参阅第二实施例中的相应内容，在此不再赘述。

步骤S203：对所述排列顺序和所述预期的账户变更数据进行显示。

客户端在获得对应的排列顺序和预期的账户变更数据后，对其进行显示，以便司机通过客户端可以实时查看自己的排列顺序，也即名次以及预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

其中，需要说明的是，司机通过客户端除了可以看见自己的排列顺序和预期的账户变更数据外，还可以看见要获得预期的账户变更数据所需满足的条件(即获奖条件)、奖励规则以及注意事项。以便司机实时知悉在哪些方面还不满足条件，从而可以定向的去完成任务，例如，接单数不满足情况，可以多接单，以保证在周期结束时，达到要求。

其中，获奖条件，例如周期内流水不小于2100元；周期内订单数不小于50单；周期内平均指派成单率不小于85％；周期结束时服务分不小于80分；周期结束时星级不小于4.5分。

其中，奖励规则，例如排名前10％(包含10％)，奖励3300元；排名前10％(不包含10％)至50％(包含50％)，奖励2200元；排名前50％(不包含50％)至90％(包含90％)，奖励1300元；排名前90％(不包含90％)至150％(包含150％)，奖励700元；排名前150％(不包含150％)至200％(包含200％)，奖励300元等。

其中，注意事项，例如，1.奖励会在本周起结束后24小时内统一发放；2.流水奖励包括基础车费、调度费、空驶补偿费和动调费；3.活动期间，有任何作弊行为，将被淘汰，所获奖励会被取消等事项。

第四实施例

本申请实施例还提供了一种应用于网约打车的服务器的数据处理装置200，如图5所示。该数据处理装置200包括：获取模块210、第一确定模块220、第二确定模块230以及发送模块240。

获取模块210，用于获取当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据。

第一确定模块220，用于基于所述接单数据确定所述多个司机终端的排列顺序。可选地，所述第一确定模块220，还用于根据预设排序规则和所述接单数据确定所述多个司机终端的每个司机终端是否有进行按照流水大小进行排序的资格；以及还用于对所述多个司机终端中有排序资格的司机终端进行按照流水大小进行排序，得到各自的排列顺序。可选地，所述第一确定模块220，还用于根据所述接单数据判断所述多个司机终端中的每个司机终端在所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意一个或任意组合是否不小于对应的预设阈值来确定所述多个司机终端中的每个司机终端是否有进行按照流水大小进行排序的资格。

第二确定模块230，用于根据所述排列顺序和预设规则确定每个所述司机终端的预期的账户变更数据。

发送模块240，用于将每个所述司机终端对应的排列顺序和预期的账户变更数据分别发送给对应的司机终端。

可选地，该数据处理装置200还包括：判断模块以及发放模块(图中未示出)。

判断模块，用于在所述当前时间点为预设结束时间点时，判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据。

发放模块，用于在所述多个司机终端中存在可以获得对应的预期的账户变更数据的第一司机终端时，向所述第一司机终端发放对应的预期的账户变更数据。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

需要说明的是，由于所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统以及装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

第五实施例

本申请实施例还提供了一种应用于网约打车的客户端的数据处理装置300，如图6所示。该数据处理装置300包括：接收模块310、获取模块320以及显示模块330。

接收模块310，用于接收查看请求。

获取模块320，用于从服务器获取所述服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据确定的排列顺序以及预期的账户变更数据。

显示模块330，用于对所述排列顺序和所述预期的账户变更数据进行显示。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

需要说明的是，由于所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统以及装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

第六实施例

本申请实施例还提供了种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述第二实施例或第三实施例所述的方法的步骤。具体实现可参见方法实施例，在此不再赘述。

具体地，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该存储介质上的程序代码被运行时，能够执行上述实施例示出的数据处理方法，通过让司机可以实时了解自己在活动内的排列顺序情况和预期的账户变更数据，从而激发司机竞争热情，保证运力稳定，减缓高峰期打车供需严重失调的难题。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，笔记本电脑，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read－OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (16)

1.一种数据处理方法，其特征在于，应用于网约打车的服务器，所述方法包括：

获取当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据；

基于所述接单数据确定所述多个司机终端的排列顺序；

根据所述排列顺序和预设规则确定每个所述司机终端的预期的账户变更数据；

将每个所述司机终端对应的排列顺序和预期的账户变更数据分别发送给对应的司机终端。

2.根据权利要求1所述的方法，其特征在于，所述基于所述接单数据确定所述多个司机终端的排列顺序，包括：

根据预设排序规则和所述接单数据确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格；

对所述多个司机终端中有排序资格的司机终端按照流水大小进行排序得到各自的排列顺序。

3.根据权利要求2所述的方法，其特征在于，所述根据预设排序规则和所述接单数据确定所述多个司机终端的每个司机终端是否有按照流水大小进行排序的资格，包括：

根据所述接单数据判断所述多个司机终端中的每个司机终端在所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意一个或任意组合是否不小于对应的预设阈值来确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格。

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

在所述当前时间点为预设结束时间点时，判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；

在所述多个司机终端中存在可以获得对应的预期的账户变更数据的第一司机终端时，向所述第一司机终端发放对应的预期的账户变更数据。

5.根据权利要求4所述的方法，其特征在于，所述判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据，包括：

通过判断所述多个司机终端中的每个司机终端是否存在作弊行为来确定所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；其中，不存在作弊行为的司机终端可以获得对应的预期的账户变更数据。

6.一种数据处理方法，其特征在于，应用于网约打车的客户端，所述方法包括：

接收查看请求；

从服务器获取所述服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据确定的排列顺序以及预期的账户变更数据；

对所述排列顺序所述预期的账户变更数据进行显示。

7.一种数据处理装置，其特征在于，应用于网约打车的服务器，所述装置包括：

获取模块，用于获取当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据；

第一确定模块，用于基于所述接单数据确定所述多个司机终端的排列顺序；

第二确定模块，用于根据所述排列顺序和预设规则确定每个所述司机终端的预期的账户变更数据；

发送模块，用于将所述每个所述司机终端对应的排列顺序和预期的账户变更数据分别发送给对应的司机终端。

8.根据权利要求7所述的装置，其特征在于，所述第一确定模块，还用于根据预设排序规则和所述接单数据确定所述多个司机终端的每个司机终端是否有按照流水大小进行排序的资格；以及还用于对所述多个司机终端中有排序资格的司机终端按照流水大小进行排序，得到各自的排列顺序。

9.根据权利要求8所述的装置，其特征在于，所述第一确定模块还用于根据所述接单数据判断所述多个司机终端中的每个司机终端在所述预设起始时间点至所述当前时间点这一时间段内的流水、订单数、成单率、服务分、星级中的任意一个或任意组合是否不小于对应的预设阈值来确定所述多个司机终端中的每个司机终端是否有按照流水大小进行排序的资格。

10.根据权利要求7－9中任一项所述的装置，其特征在于，所述装置还包括：

判断模块，用于在所述当前时间点为预设结束时间点时，判断所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；

发放模块，用于在所述多个司机终端中存在可以获得对应的预期的账户变更数据的第一司机终端时，向所述第一司机终端发放对应的预期的账户变更数据。

11.根据权利要求10所述的装置，其特征在于，所述判断模块，还用于通过判断所述多个司机终端中的每个司机终端是否不存在作弊行为来确定所述多个司机终端中的每个司机终端是否可以获得对应的预期的账户变更数据；其中，不存在作弊行为的司机终端可以获得对应的预期的账户变更数据。

12.一种数据处理装置，其特征在于，应用于网约打车的客户端，所述装置包括：

接收模块，用于接收查看请求；

获取模块，用于从服务器获取所述服务器基于预设规则和当前时间点至所述当前时间点之前的预设起始时间点这一时间段内的多个司机终端的接单数据确定的排列顺序以及预期的账户变更数据；

显示模块，用于对所述排列顺序和所述预期的账户变更数据进行显示。

13.一种服务器，其特征在于，包括：存储器和处理器，所述存储器和所述处理器连接；

所述存储器用于存储程序；

所述处理器用于调用存储于所述存储器中的程序，以执行如权利要求1－5任一项所述的方法。

14.一种司机终端，其特征在于，包括：存储器和处理器，所述存储器和所述处理器连接；

所述存储器用于存储程序；

所述处理器用于调用存储于所述存储器中的程序，以执行如权利要求6所述的方法。

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

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

Images