CN111311295A - 服务方式确定方法、装置、电子设备和存储介质 - Google Patents

服务方式确定方法、装置、电子设备和存储介质 Download PDF

Info

Publication number
CN111311295A
CN111311295A CN201811519939.3A CN201811519939A CN111311295A CN 111311295 A CN111311295 A CN 111311295A CN 201811519939 A CN201811519939 A CN 201811519939A CN 111311295 A CN111311295 A CN 111311295A
Authority
CN
China
Prior art keywords
service
type
requester
service requester
preference
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201811519939.3A
Other languages
English (en)
Other versions
CN111311295B (zh
Inventor
陈威
龚平华
王耀亚
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Priority to CN201811519939.3A priority Critical patent/CN111311295B/zh
Publication of CN111311295A publication Critical patent/CN111311295A/zh
Application granted granted Critical
Publication of CN111311295B publication Critical patent/CN111311295B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201Market modelling; Market analysis; Collecting market data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0224Discounts or incentives, e.g. coupons or rebates based on user history
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/02Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0239Online discounts or incentives
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions
    • G06Q30/0601Electronic shopping [e-shopping]

Abstract

本申请提供了服务方式确定方法、装置、电子设备和存储介质,涉及服务领域。本申请所提供的服务方式确定方法,先通过服务请求方的历史订单信息确定了服务请求方针对目标服务类型的偏好改变度,而后,再根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定了服务请求方的服务方式。使用这种确定服务方式的流程,使得确定出的服务方式更加具有针对性,按照确定的服务方式向服务请求方进行服务也能够提高服务效率,提高了用户感受度,并优化了资源配置。

Description

服务方式确定方法、装置、电子设备和存储介质
技术领域
本申请涉及服务领域,具体而言,涉及服务方式确定方法、装置、电子设备和存储介质。
背景技术
近些年,随着互联网技术的兴盛,出现了一些基于互联网技术的新兴服务业,比如网约车服务、外卖服务等。
这些新兴服务业给服务请求方和服务提供方都带来了极大的便利。这些新兴的服务业在向用户进行服务的时候,通常是由服务请求方(用户) 先在服务平台上下达服务订单,而后服务平台会将服务订单分配给某个服务提供方(如网约车司机、快递人员等)。而后,服务提供方就可以按照服务订单中的要求对服务请求方提供服务了。
发明内容
本申请的目的在于提供服务方式确定方法、装置、电子设备和存储介质。
在一些实施例中,本申请提供了一种服务方式确定方法,包括:
获取服务请求方的历史订单信息;
将服务请求方的历史订单信息输入到预先训练的偏好改变度确定模型中,得到服务请求方针对目标服务类型的偏好改变度;
根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定服务请求方的服务方式。
在一些实施例中,根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定服务请求方的服务方式,包括:
获取服务请求方针对目标服务类型的偏好改变原因;
根据服务请求方针对偏好改变度和偏好改变原因,确定服务请求方的服务方式。
在一些实施例中,获取服务请求方针对目标服务类型的偏好改变原因,包括:
获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
根据至少一种历史订单信息的变化情况,确定服务请求方的偏好改变原因。
在一些实施例中,获取服务请求方针对目标服务类型的偏好改变原因,包括:
向服务请求方发送针对偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息;
根据回复消息,确定偏好改变原因。
在一些实施例中,向服务请求方发送针对偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息,包括:
获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
根据至少一种历史订单信息的变化情况,生成针对偏好改变度的询问请求;
向服务请求方发送针对偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息。
在一些实施例中,根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定服务请求方的服务方式,包括:
获取目标服务类型的服务资源量;
根据服务请求方针对目标服务类型的偏好改变度和目标服务类型的服务资源量,确定服务请求方的服务方式。
在一些实施例中,根据服务请求方针对目标服务类型的偏好改变度和目标服务类型的服务资源量,确定服务请求方的服务方式,包括:
获取目标服务类型的服务资源量和其他服务类型的服务资源量的差别;
根据服务请求方针对目标服务类型的偏好改变度,以及目标服务类型的服务资源量和其他服务类型的服务资源量的差别,确定服务请求方的服务方式。
在一些实施例中,服务方式包括以下的任意一种或多种:
向服务请求方提供与偏好改变度相匹配的优惠券;
每隔预定时间向服务请求方发送服务优惠提示信息;
调整服务请求方在目标服务类型下的排队优先级;
调整服务请求方在目标服务类型下的服务流程。
在一些实施例中,偏好改变度确定模型是按照如下方式训练得到的:
获取训练样本;训练样本包括样本服务请求方的历史订单信息和训练样本的类型;
使用训练样本对偏好改变度确定模型进行训练。
在一些实施例中,训练样本的类型是通过如下步骤确定的:
计算样本服务请求方在第一历史时间段内发起指定类型的服务订单的第一数量占比和在第二历史时间段内发起指定类型的服务订单的第二数量占比;第一历史时间段早于第二历史时间段;
根据第一数量占比和第二数量占比的差值,确定训练样本的类型。
在一些实施例中,获取训练样本,包括:
获取样本服务请求方的活跃度;活跃度是根据以下任意一个或多个信息确定的:服务请求方下达的服务订单的数量、服务请求方下达的服务订单的类型数量和服务请求方下达服务订单的频率;
若样本服务请求方的活跃度超过预定阈值,则将样本服务请求方在预定的历史时间段内的产生的历史订单信息和训练样本的类型作为训练样本。
在一些实施例中,历史订单信息包括以下的任意一种或多种:
用户属性信息、服务订单信息、服务场景信息、服务优惠信息。
在一些实施例中,本申请提供了一种服务方式确定装置,包括:
第一获取模块,用于获取服务请求方的历史订单信息;
第一输入模块,用于将服务请求方的历史订单信息输入到预先训练的偏好改变度确定模型中,得到服务请求方针对目标服务类型的偏好改变度;
第一确定模块,用于根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定服务请求方的服务方式。
在一些实施例中,第一确定模块,包括:
第一获取单元,用于获取服务请求方针对目标服务类型的偏好改变原因;
第一确定单元,用于根据服务请求方针对偏好改变度和偏好改变原因,确定服务请求方的服务方式。
在一些实施例中,第一获取单元,包括:
第一获取子单元,用于获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
第一确定子单元,用于根据至少一种历史订单信息的变化情况,确定服务请求方的偏好改变原因。
在一些实施例中,第一获取单元,包括:
第一发送子单元,用于向服务请求方发送针对偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息;
第二确定子单元,用于根据回复消息,确定偏好改变原因。
在一些实施例中,第一发送子单元,包括:
第二获取子单元,用于获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
第一生成子单元,用于根据至少一种历史订单信息的变化情况,生成针对偏好改变度的询问请求;
第二发送子单元,用于向服务请求方发送针对偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息。
在一些实施例中,第一确定模块,包括:
第二获取单元,用于获取目标服务类型的服务资源量;
第二确定单元,用于根据服务请求方针对目标服务类型的偏好改变度和目标服务类型的服务资源量,确定服务请求方的服务方式。
在一些实施例中,第二确定单元,包括:
第三获取子单元,用于获取目标服务类型的服务资源量和其他服务类型的服务资源量的差别;
第三确定子单元,用于根据服务请求方针对目标服务类型的偏好改变度,以及目标服务类型的服务资源量和其他服务类型的服务资源量的差别,确定服务请求方的服务方式。
在一些实施例中,服务方式包括以下的任意一种或多种:
向服务请求方提供与偏好改变度相匹配的优惠券;
每隔预定时间向服务请求方发送服务优惠提示信息;
调整服务请求方在目标服务类型下的排队优先级;
调整服务请求方在目标服务类型下的服务流程。
在一些实施例中,偏好改变度确定模型是通过如下模块训练得到的:
第二获取模块,用于获取训练样本;训练样本包括样本服务请求方的历史订单信息和训练样本的类型;
第一使用模块,用于使用训练样本对偏好改变度确定模型进行训练。
在一些实施例中,训练样本的类型是通过如下模块确定的:
计算模块,用于计算样本服务请求方在第一历史时间段内发起指定类型的服务订单的第一数量占比和在第二历史时间段内发起指定类型的服务订单的第二数量占比;第一历史时间段早于第二历史时间段;
第一确定模块,用于根据第一数量占比和第二数量占比的差值,确定训练样本的类型。
在一些实施例中,第二获取模块,包括:
第三获取单元,用于获取样本服务请求方的活跃度;活跃度是根据以下任意一个或多个信息确定的:服务请求方下达的服务订单的数量、服务请求方下达的服务订单的类型数量和服务请求方下达服务订单的频率;
第三确定单元,若样本服务请求方的活跃度超过预定阈值,则用于将样本服务请求方在预定的历史时间段内的产生的历史订单信息和训练样本的类型作为训练样本。
在一些实施例中,历史订单信息包括以下的任意一种或多种:
用户属性信息、服务订单信息、服务场景信息、服务优惠信息。
在一些实施例中,本申请还提供了一种电子设备,包括:处理器、存储介质和总线,存储介质存储有处理器可执行的机器可读指令,当电子设备运行时,处理器与存储介质之间通过总线通信,处理器执行机器可读指令,以执行时执行如一种服务方式确定方法的步骤。
在一些实施例中,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如一种服务方式确定方法的步骤。
本申请所提供的方服务方式确定方法,先通过服务请求方的历史订单信息确定了服务请求方针对目标服务类型的偏好改变度,而后,再根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定了服务请求方的服务方式。使用这种确定服务方式的流程,使得确定出的服务方式更加具有针对性,按照确定的服务方式向服务请求方进行服务也能够提高服务效率,提高了用户感受度。
在一些实施例中,本申请所提供的方法中,公开了考虑具体的偏好改变原因来确定服务方式的方案,这种方案进一步提高了服务方式的针对性。
在一些实施例中,本申请所提供的方法中,公开了通过询问服务请求方的方式来确定偏好改变原因的方案,提高了确定偏好改变原因的准确度。
在一些实施例中,本申请所提供的方法中,公开了通过分析历史订单信息的变化情况来确定偏好改变原因的方案,避免过度打扰用服务请求方,并且缩短的确定的周期。
在一些实施例中,本申请所提供的方法中,公开了基于目标服务类型的服务资源量和服务请求方针对目标服务类型的偏好改变度来确定服务方式的方案,优化了资源配置。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1示出了本申请实施例所提供的服务方式确定方法的基本流程图;
图2示出了本申请实施例所提供的服务方式确定方法的细节优化流程图;
图3示出了本申请实施例所提供的服务方式确定方法中,对偏好改变度确定模型进行训练的流程图;
图4示出了是本申请一些实施例的服务方式确定方法所在的服务系统的框图;
图5示出了本申请实施例所提供的电子设备的示意图。
具体实施方式
下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
相关技术中,随着互联网技术的兴起,出现了一些基于互联网技术的新兴服务业,比如网约车服务、外卖服务、快递服务等。
以网约车服务为例,在服务请求方享受网约车服务时,首先要由服务请求方(如用户)向服务平台(服务器)下达服务订单,而后,服务平台(服务器)会将服务订单向某些服务提供方(如司机)广播,服务提供方在收到广播后,可以选择回复该广播或者是忽略该广播,进而服务平台可以根据服务提供方回复该广播的情况来确定将该服务订单分配给哪个服务提供方。进而,在服务平台将服务订单分配给指定的服务提供方后,被分配服务订单的服务提供方就可以按照服务订单中的要求来运送服务请求方,进而完成网约车服务了。
上述内容介绍了网约车的基本服务,在这基本服务的基础上,还可以将服务进行细化,比如,网约车服务可以具体分为专车服务、出租车服务、快车服务等。除了按照服务类型,将网约车服务进行细分以外,还有其他的增值服务,比如某些优惠服务、便捷服务等等。可见网约车服务中可以细分为很多种具体的服务。
类似的,其他新兴服务业,如外卖服务、快递服务也可以细分为多种不同的具体服务。比如外卖服务可以分成需要运送保鲜食品的外卖、运送一般食品的外卖等;又比如快递服务可以分成特快专递、一般快递等。类似的,其他的新兴服务业也可以分成很多的服务类型。
不论是哪种类型的服务,在具体提供服务时,都会有对应的服务策略。此处的服务策略具体有很多种,比如,某种服务的具体流程、服务价格等。
相关技术中,通常每种服务类型所对应的服务策略都是固定的,也就是服务请求方在接受服务时都是按照固定不变的标准来执行,没有根据服务请求方的具体情况来调整服务策略,这使得服务请求方的用户感受度不够好,并且服务的针对性较差。
应对于上述情况,如图1所示,本申请提供了一种服务方式确定方法,包括:
S101,获取服务请求方的历史订单信息;
S102,将服务请求方的历史订单信息输入到预先训练的偏好改变度确定模型中,得到服务请求方针对目标服务类型的偏好改变度;
S103,根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定服务请求方的服务方式。
步骤S101中,历史订单信息指的是服务请求方曾经下达过的服务订单的相关信息,通常历史订单信息是伴随着服务订单一同记录的。一般情况下,历史订单信息可以包括如下四种信息中的任意一种或多种:
用户属性信息、服务订单信息、服务场景信息、服务优惠信息。
其中,用户属性信息可以是用来描述服务请求方个人情况的信息,比如,用户属性信息可以包括如下的任意一种或多种:服务请求方的年龄、性别、职业、消费能力、守时程度、从事某个行业的工作年限、用户常住地等。这些用户属性信息通常描述的是受用户自身情况所决定的信息。
其中,守时程度反映的是服务请求方是否按照服务订单中所约定好的时间到达指定位置,或者是完成指定的工作的情况;又或者,守时程度反映的是服务请求方实际到达约定位置的时间与服务订单中所约定好的到达约定位置的时间的时间差;又或者,守时程度反映的是服务请求方实际完成预定工作的时间与服务订单中所约定好的完成预定工作的时间的时间差;
守时程度在不同领域中都会使用到,比如,在网约车领域中,守时程度可以是指服务请求方在下达服务订单后,是否按照服务订单中的上车时间到达上车地点。又比如,在快递服务中,发送快递的服务请求方是否按照服务订单中约定的上门取件时间准备好快递。又比如,在外卖服务中,商家是否按照服务定单中的所约定好的时间制备好了食物。通常,守时程度是需要通过服务订单具体完成的情况来确定的,比如守时程度可以是服务提供方上传的。或者是,守时程度也可以是服务器根据服务请求方的位置或服务提供方的位置的变化情况确定的。
服务订单信息可以是用来描述和服务订单本身相关的信息。比如,服务订单信息可以包括如下的任意一种或多种:服务类型、服务地点、服务时间、服务价格、服务路线、服务等待时间等。
其中,服务类型如专车类型、快车类型、特快专递、一般快递等具体的服务订单的类型。
当然,服务类型也可以是基于上述几种类型的细化,比如对于专车类型而言,可以将专车类型细化为服务订单的订单价格为A-B之间的专车类型,和服务订单的订单价格为C-D之间的专车类型。
又比如,对于专车类型而言,可以将专车类型细化为服务订单的行驶距离为A-B之间的专车类型,和行驶距离为C-D之间的专车类型。
服务地点可以是指服务请求方和服务提供方交接的地址(比如,网约车司机接乘客上车的点,快递取件的地点,外卖送货的地点等)。
服务时间通常有三种情况,分别是服务开始的时间(如网约车服务中乘客上车的时间)、服务结束的时间(如网约车服务中乘客下车的时间)和服务持续的时间(如网约车服务中运载乘客的时间)。
服务价格通常是指服务请求方为该订单实际支付的金额,该金额可以是服务请求方未使用优惠信息(如优惠券、代金券等)的价格,也可以是指服务请求方使用了优惠信息后的价格。
此处,服务等待时间指的是乘客从下达服务订单到接受到服务的时间差(如服务等待时间可以是指:乘客下达服务订单的时间与司机到达服务订单约定地点的时间的差值,该服务等待时间反映出了司机接乘客的速度)。
服务路线通常指的是运送的路线,比如网约车服务中,司机运送乘客的路线,又或者是快递服务中,快递员运送快递的路线。
服务场景信息主要是用来说明服务订单在执行时所在的环境的信息。比如,在网约车领域中,服务场景信息可以是指服务订单中所记录的服务请求方上车位置所在的场景(如酒店、商场、机场、地铁等场景)、下车位置所在的场景等。这些场景可以是直接根据服务订单的服务位置确定出的,比如可以根据服务定单中的上车位置来确定出上车位置所在的场景是哪个。具体的,此处的场景,除了可以是具体按照场景的类型来划分,还可以按照场景的消费水平划分。也就是,服务场景信息包括以下任意一种或多种信息:场景类型、场景消费水平、场景大小等和场景有关的消息。
服务优惠信息指的是服务订单在执行时是否使用了优惠信息,比如是否使用了优惠券、折扣卷、代金券等能够影响服务价格的信息;又或者是服务订单中具体使用的优惠券、折扣卷、代金券等能够影响服务价格的信息的情况(如优惠信息的折扣比例等)。
服务器中会存储有每个服务订单的相关信息,进而服务器可以从存储的服务订单的相关信息中确定历史订单信息。历史订单信息还可以是通过对服务提供方和服务请求方进行调研的方式获得。
步骤S102中,可以直接将服务请求方的历史订单信息输入到预先训练的偏好改变度确定模型中,进而得到服务请求方针对目标服务类型的偏好改变度。此处的偏好改变度反映了服务请求方针对某一种服务类型的服务的喜好改变情况。具体而言,偏好改变度有如下三种情况:更喜欢某种类型的服务的幅度、更不喜欢某种类型的服务的幅度和对某种类型的服务的喜好程度没有改变。
具体而言,目标服务类型的偏好改变度中,目标服务类型可以是服务订单信息中的服务类型,也可以是依据其他的历史订单信息对服务类型进行细化后的服务类型(比如对于专车类型而言,可以将专车类型细化为服务订单的订单价格为A-B之间的专车类型,和服务订单的订单价格为C-D 之间的专车类型)。
具体的,偏好改变度可以仅仅表示出偏好改变的倾向,比如更喜欢某种类型的服务的幅度、更不喜欢某种类型的服务的幅度和对某种类型的服务的喜好程度没有改变。如使用1表示服务请求方更偏好某个服务,0表示没有发生偏好改变,-1表示服务请求方更不偏好某个服务。
还可以是以连续的数值的形式来表示,以对偏好改变度进行精确的说明。如使用0、1、2、3、4…100来表示服务请求方更偏好某个服务的程度,使用0、-1、-2、-3、-4…-100来表示服务请求方更不偏好某个服务的程度。具体的,偏好改变度确定模型所输出的偏好改变度通常是0-1之间的概率,进而可以将该概率转化成0-100的数值,也可以根据该0-1之间的概率是否在某个区间中,来确定服务请求方是否更偏好某个服务,或更不偏好某个服务,或者是是否发生偏好改变。
实际上,基于历史订单信息所生成的偏好改变度,一定程度上反映了服务请求方对某种服务类型的使用趋势(或者说是喜好趋势)。从某个角度来看,可以认为在不施加外部干预的情况下,服务请求方会保持步骤S202 的偏好改变度,或者是保持当前的偏好。进而,由于服务请求方产生了偏好改变度,为了加强偏好改变度(进一步提高服务请求方喜欢某个服务类型的程度,或者进一步降低服务请求方喜欢某个服务类型的程度),或修正偏好改变度(阻止服务请求方进一步厌恶某个服务类型的程度,或阻止服务请求方进一步喜欢某个服务类型的程度),可以施加一定的干预措施,也就是,在步骤S103中,根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定服务请求方的服务方式。
比如,确定服务方式的时候,可以是如果服务请求方针对目标服务类型的偏好改变度超过预定数值,则采用A服务方式;
如果服务请求方针对目标服务类型的偏好改变度低于预定数值,则采用B服务方式。
也可以是,在确定采用某种服务方式后,根据偏好改变度的具体数值确定服务方式的服务程度(如价格优惠程度、排队优先级调整程度等)。
在具体实现时,可以在服务器中预存一个表格,而后,根据偏好改变度的数值,从表格中查找对应的服务方式,以将查找到的服务方式作为服务请求方的服务方式。
通常情况下,步骤S103在实现时,有两种实现方式,一种是只根据偏好改变度来确定服务方式,比如偏好改变度越大,则确定的服务方式所对应的服务质量就越高或越低。另一种是根据具体的一些外因来确定服务方式,比较常见的外因如服务请求方发生偏好改变的原因,又比如某种服务的服务资源(比如,能够提供某种类型的服务的人员数量)等。
对于只根据偏好改变度来确定服务方式的实现方式而言,实现过程相对简单。具体来说,可以是服务请求方越不偏好某个类型的服务,则针对该服务的服务质量就应当越高(比如可以提供更多的优惠,或者是提高排队的优先级);也可以是服务请求方越偏好某个类型的服务,则针对该服务的服务方式就应当越保持现状(服务请求方越偏好某种服务,则说明服务请求方对当前的服务很满意,因此服务方式不应当调整)。
如下表1所示,示出了偏好改变度和服务方式的对应关系:
表1
Figure BDA0001902969260000141
表1中示出了两种服务类型(专车服务和快车服务)在不同偏好改变度情况下的服务方式(表1中,偏好度增加说明服务请求方更偏好、更喜欢该服务)。可以看出,在服务请求方对快车的偏好度减少的时候,可以通过提高快车排队的优先级的方式来使得服务请求方对专车服务的偏好度增加。类似的,在服务请求方对专车的偏好度减少的时候,可以通过提高专车排队的优先级的方式来使得服务请求方对专车服务的偏好度增加。此处,提高排队优先级可以使得服务请求方在下达服务订单之后,能够更快速的将服务订单分配给司机,也就可以让服务请求方更快的上车。除了提高专车排队的优先级,还可以是如表1中所示,通过向服务请求方提供专车服务的优惠券,来使得服务请求方可以有动力继续使用专车服务。
表1中,编号为3的一行,表示的是当服务请求方使用快车的好感度增加的时候,可以向服务请求方提供专车服务的优惠券,使得服务请求方有动力使用更高级的服务。还可以是如表1中编号为1的一行,在服务请求方对专车的偏好度增加后,对应的服务方式是保持已有的服务方式。也就是,按照当前的服务方式对服务请求方继续进行服务即可,不需要调整服务方式了。
在表1所示出的内容的基础上,可以看出,如果服务请求方对某个服务类型(目标服务类型)的偏好改变度下降了,则可以当向服务请求方提供目标服务类型的优质服务引导信息(服务方式的一种,如提供目标服务类型所对应的优惠券、提高目标服务类型的排队优先级);如果服务请求方对某个服务类型(目标服务类型)的偏好改变度上升了,则可以向服务请求方提供比目标服务类型更高级的服务类型所对应的优质服务引导信息 (服务方式的一种,如提供目标服务类型所对应的优惠券、提高目标服务类型的排队优先级),以引导服务请求方使用高级服务。具体的,如表1中所示,专车就可以认为是快车的高级服务。具体实现时,不同服务之间的高级和低级的相对关系可以是服务请求方根据情况进行调整的,并不必然收费高的就是高级服务。
表1中列举出了两种服务类型(专车服务和快车服务)在不同偏好改变度情况下的服务方式,在这基础上,还可以是根据偏好改变度的数值,将服务方式进行细化。进而,可以得到如下表2所示的对应关系:
表2
Figure BDA0001902969260000151
Figure BDA0001902969260000161
表2中示出了服务请求方针对快车服务发生了偏好改变的情况下,不同偏好改变度所对应的服务方式。
可以看出,随着偏好度减少幅度(偏好度减少一定程度上说明服务请求方不喜欢这项服务)的增加,向服务请求方提供的服务方式越来越有利。从不改变服务方式,到向服务请求方提供10元、20元的优惠券。使得服务请求方的偏好度减少的越多,提供的优惠越大。
具体的,服务方式可以包括以下的任意一种或多种:
向服务请求方提供与偏好改变度相匹配的优惠券;
每隔预定时间向服务请求方发送服务优惠提示信息;
调整服务请求方在目标服务类型下的排队优先级;
调整服务请求方在目标服务类型下的服务流程。
其中,优惠券可以是折扣卷、代金券等能够调整服务请求方最终支付金额的信息。具体的优惠券的优惠程度可以是根据偏好改变度、偏好改变原因和服务资源量确定的。
每隔预定时间向服务请求方发送服务优惠提示信息,指的是向服务请求方提示某个时期会有优惠活动,比如,在某个假期中,下达的服务订单较为便宜。通过这种方式能够引导服务请求方在指定时间区域内下达服务订单。
排队优先级指的是,当多个服务请求方同时发起请求服务时(多个服务请求方均下达了服务订单时),每个服务请求方的服务订单被分配的先后顺序。或者排队优先级指的是,当多个服务请求方同时发起请求服务时(多个服务请求方均下达了服务订单时),每个服务请求方被服务的顺序。进而,在调整排队优先级后,在同等条件下,服务请求方就可以更早,或更晚的接收到服务了。
服务流程指的是某种服务在进行时,各个步骤执行的先后顺序。进而,在调整服务流程的时,可以是在原有的服务流程中增加某个流程步骤,也可以是减少某个流程步骤。比如,减少验证的环节,以加快服务效率,或者是增加采集服务请求方个人信息,并根据个人信息调整服务策略的环境,以提高服务的针对性,提高用户感受度。
此处调整的服务流程和排队优先级只是针对步骤S101中的服务请求方的,对于步骤S101中服务请求方以外的用户,排队优先级和服务流程不做调整。
上述内容介绍了只根据偏好改变度来确定服务方式的过程,还可以是同时根据偏好改变原因和偏好改变度来确定服务方式。具体的,本申请所提供的方法中,步骤S103还可以按照如下方式实现:
步骤1031,获取服务请求方针对目标服务类型的偏好改变原因;
步骤1032,根据服务请求方针对目标服务类型的偏好改变度和偏好改变原因,确定服务请求方的服务方式。
步骤1031中,偏好改变原因可以认为是指服务请求方下达历史订单产生变化的原因(由于偏好改变度是根据历史订单信息确定的,因此,询问服务请求方下达历史订单的原因就可以认为是服务请求方产生偏好改变度的原因)。具体的,偏好改变原因可能有很多,比如服务请求方认为价格过高、不喜欢指定服务的APP界面、服务请求方认为服务流程太复杂等等。
通常情况下,偏好改变原因主要是用来确定服务方式的具体种类(如偏好改变原因是价格过高,则确定的服务方式是提供优惠券),偏好改变度可以用来调整服务方式的具体程度,比如具体金额的多少,优先级的级别高低等。
此处,获取服务请求方针对目标服务类型的偏好改变原因的方式有三种,第一种是利用历史订单信息来自行确定的方式(可以不在服务请求方的帮助下来确定偏好改变原因);第二种是必须依靠服务请求方的帮助来确定偏好改变原因。
下面分别针对每种确定偏好改变原因的方式进行说明:
第一种确定偏好改变原因的方式:
步骤1031可以按照如下方式实现:
步骤10311,获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
步骤10312,根据至少一种历史订单信息的变化情况,确定服务请求方的偏好改变原因。
步骤10311中,过去预定时间内可以是指从服务请求方第一次产生历史订单信息开始,到当前时间的这段时间。也可以是指历史上的任意一段时间。与目标服务类型相关的至少一种历史订单信息的变化情况可以是指某一种历史订单信息的变化程度,或者是是否发生变化。比如,可以使用如下表格3来表示历史订单信息的变化情况。
表3
Figure BDA0001902969260000181
如表3中所示,示出了在3-6月份不同历史订单信息的变化情况。可以看出,快车服务等待时间所对应的平均服务等待时间增加10分钟,这说明了服务请求方的服务感受度下降了(由于乘客的等待时间过长)。此处,服务等待时间指的是乘客从下达服务订单到接受到服务的时间(如服务等待时间可以是指:乘客下达服务订单的时间与司机到达服务订单约定地点的时间的差值,该服务等待时间反映出了司机接乘客的速度)。快车服务价格提高了20元可以反映出乘客支出方面提高了。快车守时程度始终保持在5 分钟左右到达指定地点,表示了乘客依旧是遵守时间的,即始终在5分钟左右到达服务订单中所约定的地点。快车呼叫场景的变化为服务区域的位置由偏远地区向市中心转移,指的是乘客的出行地点越来越靠近市中心了。
进而,如果表3所对应的乘客对快车的偏好改变度下降,则通过表3 中的内容,步骤10312中可以确定偏好改变原因可能是服务价格提高了,或者是平均服务等待时间增加了。此时,可以确定服务方式为提高乘客的快车排队的优先级,这样就能使乘客继续使用快车服务了。当然,也可以通过向乘客提供优惠券,来降低乘客使用快车服务的成本。
也就是,偏好改变原因可以用来确定服务方式的具体种类,偏好改变度可以用来调整服务方式的具体程度,比如具体金额,优先级的级别等。
需要说明的是,某些情况下,单纯凭借某个参数无法准确的确定偏好改变原因,比如,某些情况下,服务价格无法独立评价决定成本,还需要考虑服务路程长度来确定出单位路程所对应的服务价格(如每公里的价格)。此时,也就需要至少两个历史订单信息来确定出偏好改变原因了。
第二种确定偏好改变原因的方式:
步骤1031可以按照如下方式实现:
步骤10313,向服务请求方发送针对目标服务类型的偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息;
步骤10314,根据回复消息,确定偏好改变原因。
与第一种确定偏好改变原因的方式相比,第二中确定偏好改变原因的方式主要是依赖于服务请求方的回复。
即步骤10313中,首先需要向服务请求方发送针对目标服务类型的偏好改变度的询问请求,该询问请求可以是由至少一个格式化的问题所组成,也可以是由至少一个非格式化的问题所组成的。
此处的格式化的问题指的是题目的答案是相对固定的,比如某个选择题的问题可以是“请说明当前快车服务所存在的问题”,对应的可选择的格式化答案有“价格过高”、“服务等待时间过长”等待。服务请求方可以自由的选择将这些答案中的任何一个携带在回复消息中。
此处的非格式化的问题指的是题目的答案是不固定的,比如问题可以是“请说明当前快车服务所存在的问题”,而后,可以让服务请求方来输入一段文字作为答案。
不论是格式化的问题还是非格式化的问题,都可以将服务请求方所输入的答案作为回复消息。
在服务器接收到回复消息之后,就可以根据答案来确定偏好改变原因了。具体的,如果是针对格式化的问题的答案,则通常可以直接将答案作为偏好改变原因,因为这些格式化的答案通常都是预先设置好,便于服务器直接使用的。如果是针对非格式化的问题的答案,则通常需要先使用语义分析工具,服务请求方所答案的文字进行分析,并将语义分析的结果输入到语言分析模型中,以确定语义分析结果与哪个格式化的答案最相似,进而确定服务请求方所答案的文字表示了哪个格式化的答案。
在第二种确定偏好改变原因的方式基础上,还可以将第一种确定偏好改变原因的方式融合到第二种确定偏好改变原因的方式中,也就是,如图2 所示,步骤10313可以按照如下方式实现:
步骤S10315,获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
步骤S10316,根据至少一种历史订单信息的变化情况,生成针对目标服务类型的偏好改变度的询问请求;
步骤S10317,向服务请求方发送针对目标服务类型的偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息。
可以看出,步骤S10315中,过去预定时间内可以是指从服务请求方第一次产生历史订单信息开始,到当前时间的这段时间。也可以是指历史上的任意一段时间。与目标服务类型相关的至少一种历史订单信息的变化情况可以是指某一种历史订单信息的变化程度,或者是是否发生变化。具体的历史订单信息的变化情况有很多种,具体可参照步骤10311中对历史订单信息的变化情况的说明。
步骤S10316中,所具体确定的询问请求是可以是将历史订单信息的变化情况按照变化幅度进行排序,并根据排序和历史订单信息的权重,选择出适当的历史订单信息的变化情况,并且根据选择出的历史订单信息的变化情况生成询问请求。此处,权重可以是使用者根据历史订单信息的重要程度设置的,也可以是通过对乘客进行调研来确定,乘客比较看重的历史订单信息是哪个,或者是最影响用户感受度的历史订单信息是哪个。
其中,变化幅度指的是将历史订单信息的变化情况进行量化(通过数字来表达变化情况的幅度)后的结果。该变化幅度可以以数字的方式表征出每个历史订单信息的改变程度(比如提高了10%,降低了15%等)。进而,可以通过如下表4来表征根据历史订单信息的变化情况。
表4
Figure BDA0001902969260000211
Figure BDA0001902969260000221
表4中,服务等待时间指的是乘客下达服务订单的时间与司机到达服务订单所约定地点的时间的差值,该服务等待时间反映出了司机接乘客的速度。每个服务订单的总服务价格,指的是乘客为一个服务订单所支付的实际价格;与此相对应的,每公里的服务价格指的是乘客在接受服务的过程中,每公里所支付的金额。该每公里的服务价格可以是根据服务订单的总服务价格和总公里数的比值来确定。乘客由下达服务订单的地点移动到上车地点的距离主要反映的是乘客在下达了服务订单之后,还需要移动多少距离才能到达上车地点(司机接乘客的地点)。
如表4所示,使用了百分比的形式来表征了变化幅度。可以看出,引入了变化幅度,实际上就是将各个历史订单信息的变化情况的评价标准统一到一个标准下,否则有的是以价格作为评价标准,有的是以时间作为评价标准,有的则是以距离作为评价标准,这会导致各个历史订单信息的变化情况难以同时进行比较。进而,在引入了变化幅度之后,就可以将不同的历史订单信息的变化情况进行横向比较了。
通过表4可以看出服务等待时间的变化幅度最大,达到了26%,因此,乘客的偏好改变原因极有可能是因为服务等待时间过长。同时,每个服务订单的总服务价格和乘客由下达服务订单的地点移动到上车地点的距离的变化幅度也较大,因此乘客的偏好改变原因也很有可能是因为这两个原因。实际使用的时候,可以将每个历史订单信息的权重设置为1,这样就可以直接根据变化幅度最大一个或多个的历史订单信息的变化情况生成询问请求了。
当权重不为1的时候,则需要将使用权重对每个变化幅度再进行一次调整,比如,可以将权重与变化幅度的乘积作为最终的评价值,并根据评价值最高的一个或多个历史订单信息的变化情况生成询问请求。
生成的询问请求中,所携带的具体问题应当是与变化幅度最大一个或多个的历史订单信息的变化情况相对应的,或者是与评价值最高的一个或多个历史订单信息的变化情况相对应的。比如,如表4所示,在确定了服务等待时间变化幅度最大的之后,就可以在询问请求中携带上如下问题“是否感觉服务等待时间过长”,或者是携带上如下问题“请说明3-6月份对服务等待时间的评价”。这样就可以让服务请求方针对性的回复关于服务等待时间的评价内容了。
其余询问请求的具体内容(组成)可以如步骤10313中的介绍,此处不再重复说明。
在生成了询问请求之后,就可以在步骤S10317中向服务请求方发送询问请求,并由服务请求方生成针对该询问请求的回复消息,进而,就可以根据回复消息确定偏好改变原因了。
步骤S10315-S10317可以认为是先由服务器自动确定一些出很大可能导致产生偏好改变度的原因,而后通过向服务请求方询问的方式,让服务请求方从自动确定出的原因中选择出更加准确的原因。通过这种自动+人工 (服务请求方生成回复消息)的方式,能够更加准确的确定出真实的偏好改变原因,并且,相对于基本的步骤10313-步骤10314而言,能够提高服务请求方回答的质量(第二种确定偏好改变原因的方式中,为了保证询问的全面性,携带在询问请求中的问题通常是大量的,这会导致服务请求方需要花费较长的时间来回答这些问题,影响了用户感受度)。
上第一种确定偏好改变原因的方式基本不需要服务请求方参与,避免打扰到服务请求方。第二种确定偏好改变原因的方式与第一种方式相比,所确定出的偏好改变原因会更加准确,主要是由于确定偏好改变原因的依据都是服务请求方自己提供的,能够更加准确的反映出服务请求方的实际想法。
不论采用哪种实现方式,偏好改变原因均可以认为用来确定服务方式的具体种类,偏好改变度可以是用来确定调整服务方式的具体程度,比如具体金额,优先级的级别等。
前文中介绍了根据偏好改变原因来确定服务方式的方法,除了这种确定服务方式的方法之外,还可以是根据服务资源量来确定服务方式。此处,服务资源量指的是能够向服务请求方提供服务的资源的数量,具体的,服务资源量可以是剩余服务资源量(处于空闲状态的服务资源的数量,或者是目前能够直接向服务请求方提供服务的服务资源的数量),也可以是服务资源总量。此处的服务资源总量可以认为是目前已有全部服务资源的数量 (不论服务资源是否处于空闲状态),在此基础上,还可以将未来一段时间内可以得到的服务资源量(如即将成为某类型司机的数量)作为服务资源总量。
具体的,服务资源量可以是指能够提供某种类型的服务的人员数量、能够提供某种类型的服务的设备数量(如车辆、飞机等运载工具的数量) 等。
进而,在利用服务资源量确定服务方式的时候,步骤S103可以按照如下方式实现:
步骤1033,获取目标服务类型的服务资源量;
步骤1034,根据服务请求方针对目标服务类型的偏好改变度和目标服务类型的服务资源量,确定服务请求方的服务方式。
具体的,步骤1033中,所获取到的服务资源量可以是步骤S102中目标服务类型的服务资源量,也可以是指同时包含步骤S102中目标服务类型和其他服务类型的服务资源量。
具体而言,如果目标服务类型的服务资源较少的话,则可以引导服务请求方使用其他服务类型的服务。具体的引导方式可以是向服务请求方提供其他服务类型的服务的优惠券,或者是提高服务请求方使用其他服务类型的服务时的排队优先级。更具体的,偏好改变度的大小和服务资源量的多少可以是决定引导的幅度(比如优惠券的金额,排队优先级的程度等)。
此处,服务资源量可以用来确定服务方式的具体种类(如果目标服务类型的服务资源量过少,则确定的服务方式是引导服务请求方使用其他服务类型的服务,比如可以提供其他服务类型的服务的优惠券,或者是提高其他服务类型的排队优先级),偏好改变度可以用来调整服务方式的具体程度,比如具体金额,优先级的级别等。
从某个角度来看,确定服务资源量的目的主要有两个,第一个目的是确认偏好改变度的产生是否和服务资源量有关系。比如,如果某个服务的服务资源量过少/减少,则服务请求方排队的时间必然会延长,此时,可以更加准确的确定偏好改变度是由于服务资源量的情况所导致的。
第二目的是确认是否要根据服务资源量去引导服务请求方改变服务类型。比如,在某些情况下,专车的服务资源量过少,而快车的服务资源量较多,则应当引导服务请求方更多的使用快车服务,而不是专车服务。具体采用的引导方式可以是向服务请求方提供快车的优惠卷,又或者是提高服务请求方使用快车的排队优先级。
进而,为了更加有针对性的实现方案,步骤1034在实现时,可以按照如下方式实现:
步骤10341,获取目标服务类型的服务资源量和其他服务类型的服务资源量的差别;
步骤10342,根据服务请求方针对目标服务类型的偏好改变度,以及目标服务类型的服务资源量和其他服务类型的服务资源量的差别,确定服务请求方的服务方式。
其中,目标服务类型的服务资源量和其他服务类型的服务资源量的差别反映了目标服务类型和其他服务类型能够提供服务的能力差别。目标服务类型的服务资源量比其他服务类型的服务资源量少,则说明目标服务类型的服务资源量向服务请求方提供服务的能力,比其他服务类型的服务资源量向服务请求方提供服务的能力差。
在确定了目标服务类型的服务资源量和其他服务类型的服务资源量的差别后,就可以依据该差别确定出对应的服务方式了,具体的,目标服务类型的服务资源量和其他服务类型的服务资源量的差别主要用来确定服务方式的具体种类,偏好改变度和目标服务类型的服务资源量和其他服务类型的服务资源量的差别可以共同用来调整服务方式的具体程度,比如具体金额,优先级的级别等。
具体的,步骤10342有如下几种情况:
第一种情况,服务请求方针对目标服务类型(如A服务类型)的偏好改变度为下降(说明服务请求方不喜欢目标服务类型的服务),并且目标服务类型的服务资源量比其他服务类型(如B服务类型)的服务资源量的少,则确定的服务方式是引导服务请求方使用其他服务类型的服务。这主要是当目标服务类型的服务资源较少的时候,通常无法满足服务请求方的需求,如果不加以干预(让服务请求方继续使用A类型的服务)这会导致服务请求方的对A类型的服务更加不满意,因此,此时应当及时引导服务请求方使用其他服务类型的服务。
引导服务请求方使用其他服务类型的服务的具体方式可以是:向服务请求方提供B服务类型的优惠券,也可以是提高服务请求方使用B服务类型的服务时的排队优先级。
第二种情况,服务请求方针对目标服务类型(如A服务类型)的偏好改变度为下降(说明服务请求方不喜欢目标服务类型的服务),并且目标服务类型的服务资源量比其他服务类型(如B服务类型)的服务资源量的多,则确定的服务方式可以是引导服务请求方继续使用目标服务类型的服务。这主要是当目标服务类型的服务资源较多的时候,依旧无法满足服务请求方的需求,则使用服务资源量较少的服务类型就更无法满足服务请求方的需求了,因此,此时应当引导服务请求方继续使用A服务类型的服务。
引导服务请求方继续使用A服务类型的服务的具体方式可以是:向服务请求方提供A服务类型的优惠券,也可以是提高服务请求方使用A服务类型的服务时的排队优先级。
第三种情况,服务请求方针对目标服务类型(如A服务类型)的偏好改变度为上升降(说明服务请求方喜欢目标服务类型的服务),并且目标服务类型的服务资源量比其他服务类型(如B服务类型)的服务资源量的少,则确定的服务方式可以是如果A服务类型的服务内容和B服务类型的服务内容相似,则引导服务请求方使用B服务类型的服务。
这主要是当目标服务类型的服务资源较少的时候,依旧能够满足服务请求方的需求,则说明服务请求方对A服务类型的服务很满意,但考虑到服务资源的剩余量,则应当考虑引导服务请求方使用其他服务类型的服务,以使其他服务请求方能够使用A服务类型的服务。
引导服务请求方使用其他服务类型的服务的具体方式可以是:向服务请求方提供B服务类型的优惠券,也可以是提高服务请求方使用B服务类型的服务时的排队优先级。
第四种情况,服务请求方针对目标服务类型(如A服务类型)的偏好改变度为上升降(说明服务请求方喜欢目标服务类型的服务),并且目标服务类型的服务资源量比其他服务类型(如B服务类型)的服务资源量的少,则确定的服务方式可以是如果A服务类型的服务内容和B服务类型的服务内容不相似,则终止操作(不对服务请求方进行影响)。
这主要是当A服务类型的服务内容和B服务类型的服务内容不相似的时候,如果贸然的引导服务请求方使用B服务类型的服务,则有可能导致用户感受度的下降。具体实现时,可以根据A服务类型的服务内容调整B 服务类型的服务内容,使得二者相似度增加。
第五种情况,服务请求方针对目标服务类型(如A服务类型)的偏好改变度为上升降(说明服务请求方喜欢目标服务类型的服务),并且目标服务类型的服务资源量比其他服务类型(如B服务类型)的服务资源量的多,则终止操作(不对服务请求方进行影响)。
这主要是当目标服务类型的服务资源较多的时候,能够满足服务请求方的需求,则说明服务请求方对A服务类型的服务很满意,同时考虑到A 服务的服务资源量较多,而B服务的服务资源量较少,则不应当引导服务请求方使用B服务类型的服务,以免B服务类型的服务压力过大;同时,如果向服务请求方提供A服务类型的优惠,则可能会导致其他使用A服务类型的用户的服务感受度下降,因此,此时最好不采用具体的服务方式,或者说确定的服务方式为不处理。
通过上述5种具体的情况可以看出,通过引入了服务资源量,可以使得方案变得更加有针对性,通过服务资源量来确定服务方式,使得确定出的服务方式能够对服务资源进行更合理的配置,也就是优化了资源配置。
在上述两种方案(依据服务资源量确定服务方式和依据偏好改变原因确定服务请求方的服务方式)的基础上,本申请所提供的方法中,还可以同时根据服务偏好改变原因和服务资源量来确定服务方式,也就是,本申请所提供的方案中,步骤S103可以按照如下方式实现:
根据服务请求方针对目标服务类型的偏好改变度、偏好改变原因和至少一种服务类型的服务资源量,确定服务请求方的服务方式。
获取偏好改变原因的方式已经在前文中进行说明,具体的,同时利用这三个信息来确定服务方式的具体策略可以根据实际情况进行调整,此处,不过多说明。
通常情况下,偏好改变原因可以用来确定服务方式的具体种类,偏好改变度和目标服务类型的服务资源量和其他服务类型的服务资源量的差别可以用来共同调整服务方式的具体程度,比如具体金额,优先级的级别等。
或者是,通常情况下,偏好改变原因和目标服务类型的服务资源量和其他服务类型的服务资源量的差别可以用来共同确定服务方式的具体种类,偏好改变度和目标服务类型的服务资源量和其他服务类型的服务资源量的差别可以用来共同调整服务方式的具体程度,比如具体金额,优先级的级别等。
上述内容介绍了服务方式的确定过程,下面对偏好改变度确定模型的训练过程进行说明。
如图3所示,偏好改变度确定模型是按照如下方式训练得到的:
S301,获取训练样本;训练样本包括样本服务请求方的历史订单信息和训练样本的类型;
S302,使用训练样本对偏好改变度确定模型进行训练。
其中,训练样本的类型指的是该训练样本是正样本还是负样本。确定训练样本是正样本还是负样本的过程,可以由人工来选择,也可以是由服务器自动完成。
当确定训练样本是正样本还是负样本的过程是由服务器自动完成的时候,训练样本的类型是通过如下步骤确定的:
步骤401,计算样本服务请求方在第一历史时间段内发起指定类型的服务订单的第一数量占比和在第二历史时间段内发起指定类型的服务订单的第二数量占比;第一历史时间段早于第二历史时间段;
步骤402,根据第一数量占比和第二数量占比的差值,确定训练样本的类型。
步骤401中,第一数量占比指的是在第一历史时间段内,样本服务请求方曾经发起的某种类型的服务订单数量与全部类型的服务订单数量的比值。类似的,第二数量占比指的是在第二历史时间段内,样本服务请求方曾经发起的某种类型的服务订单数量与全部类型的服务订单数量的比值。也就是,第一数量占比和第二数量占比都是指定类型(如快车)的服务订单数量和总订单数量(快车订单、专车订单、拼车订单等订单)的比值。该比值反映出了服务请求方对某种服务类型的偏好程度,比如快车订单占总订单量的95%,则说明服务请求方很喜欢使用快车服务;反之,如果快车订单占总订单量的1%,则说明服务请求方很不喜欢使用快车服务。
由于第一数量占比和第二数量占比是反映了不同时间段的统计结果,因此,第一数量占比和第二数量占比的差值就能够反映出了不同时间段中服务请求方对某种服务类型的喜好程度的变化情况。
进而,步骤402中,根据第一数量占比和第二数量占比的差值,确定训练样本的是正样本还是负样本了(一般来说,差值超过一定的数值就可以将训练样本作为正样本,反之,就作为负样本)。
在确定了训练样本的类型之后,就可以使用训练样本对偏好改变度确定模型进行训练,进而得到训练完成的模型了。
此处使用的偏好改变度确定模型可以选择常见的分类器,如逻辑回归(Logistics Regression)模型,支持向量机(Support Vector Machine)模型,决策树(Decision Tree)模型,以及梯度提升决策树(Gradient Boosting Decision Tree)模型。除此之外,也可以选择使用深度机器学习(神经网络) 模型。若使用神经网络模型,则在将数据输入到模型前,需要对数据进行归一化处理,并采取适合的初始化方案,以保证模型可以收敛到一个较优的状态。
在确定训练样本的时候,还可以考虑服务请求方的活跃度,只有活跃度足够高的服务请求方的数据才能够作为训练样本,这样训练的针对性和效率会更高,也就是,步骤S301,可以按照如下方式实现:
步骤3011,获取样本服务请求方的活跃度;活跃度是根据以下任意一个或多个信息确定的:样本服务请求方下达的服务订单的数量、样本服务请求方下达的服务订单的类型数量和样本服务请求方下达服务订单的频率;
步骤3012,若样本服务请求方的活跃度超过预定阈值,则将样本服务请求方在预定的历史时间段内的产生的历史订单信息和训练样本的类型作为训练样本。
步骤3011中,样本服务请求方下达的服务订单的数量可以包括如下两种数量中的任意至少一种:样本服务请求方下达的全部服务订单的数量(每个服务类型所对应服务订单数量的总和)和样本服务请求方下达的至少一种服务类型(如目标服务类型)的服务订单的数量。
样本服务请求方下达的服务订单的类型数量指的是样本服务请求方下达的服务订单共有多少个类型。比如,共有3种服务类型(分别是专车订单、快车订单和出租车订单),其中,下达的专车订单有10个,出租车订单为0,快车订单为6,则下达服务订单的数量类型为2(有专车订单和出租车订单两种订单)。
样本服务请求方下达服务订单的频率可以包括如下两种频率中的任意至少一种:样本服务请求方下达的全部服务订单的频率(不区分服务订单的类型,可以将所有类型的服务订单下达数量与下单总时长的比值作为该频率)和样本服务请求方下达的至少一种服务类型(如目标服务类型)的服务订单的频率(区分服务订单的类型,可以将指定类型的服务订单下达数量与该指定类型的下单总时长的比值作为该频率)。
进而,根据样本服务请求方下达的服务订单的数量、样本服务请求方下达的服务订单的类型数量和样本服务请求方下达服务订单的频率中的任意一种或多种就能够确认出样本服务请求方是否足够活跃,是否有参考价值。而后,在步骤3012中,可以直接将活跃度足够高的样本服务请求方在预定的历史时间段内的产生的历史订单信息和训练样本的类型作为训练样本。
具体实现时,为了简化操作,可以直接考察样本服务请求方下达的全部服务订单的数量是否超过预定数值,来确定是否将样本服务请求方的历史订单信息和训练样本的类型作为训练样本。
如图4所示,示出了是本申请一些实施例的服务方式确定方法所在的服务系统100的框图。例如,服务系统100可以是用于诸如出租车、代驾服务、快车、拼车、公共汽车服务、驾驶员租赁、或班车服务之类的运输服务、或其任意组合的在线运输服务平台。服务系统100可以包括服务器 110(本申请所提供方法的执行主体)、网络120、服务请求方终端130(服务请求方)、服务提供方终端140(服务提供方)和数据库150中的一种或多种,服务器110中可以包括执行指令操作的处理器。
在一些实施例中,服务器110可以是单个服务器,也可以是服务器组。服务器组可以是集中式的,也可以是分布式的(例如,服务器110可以是分布式系统)。在一些实施例中,服务器110相对于终端,可以是本地的、也可以是远程的。例如,服务器110可以经由网络120访问存储在服务请求方终端130、服务提供方终端140、或数据库150、或其任意组合中的信息和/或数据。作为另一示例,服务器110可以直接连接到服务请求方终端 130、服务提供方终端140和数据库150中至少一个,以访问存储的信息和 /或数据。在一些实施例中,服务器110可以在云平台上实现;仅作为示例,云平台可以包括私有云、公有云、混合云、社区云(community cloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等,或者它们的任意组合。在一些实施例中,服务器110可以在具有本申请中图5所示的一个或多个组
网络120可以用于信息和/或数据的交换。在一些实施例中,服务系统 100中的一个或多个组件(例如,服务器110,服务请求方终端130,服务提供方终端140和数据库150)可以向其他组件发送信息和/或数据。例如,服务器110可以经由网络120从服务请求方终端130获取服务请求。在一些实施例中,网络120可以是任何类型的有线或者无线网络,或者是他们的结合。仅作为示例,网络130可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(Local Area Network,LAN)、广域网(Wide Area Network,WAN)、无线局域网(Wireless Local Area Networks,WLAN)、城域网(Metropolitan Area Network,MAN)、广域网 (Wide Area Network,WAN)、公共电话交换网(Public Switched TelephoneNetwork,PSTN)、蓝牙网络、ZigBee网络、或近场通信(Near Field Communication,NFC)网络等,或其任意组合。在一些实施例中,网络120 可以包括一个或多个网络接入点。例如,网络120可以包括有线或无线网络接入点,例如基站和/或网络交换节点,服务系统100的一个或多个组件可以通过该接入点连接到网络120以交换数据和/或信息。
在一些实施例中,服务请求方终端130的服务请求方可以是除服务实际需求者之外的其他人。例如,服务请求方终端130的服务请求方A可以使用服务请求方终端130来为服务实际需求者B发起服务请求(比如,服务请求方A可以为自己的朋友B叫车),或者从服务器110接收服务信息或指令等。在一些实施例中,服务提供方终端140的服务请求方可以是服务实际提供者,也可以是除服务实际提供者之外的其他人。例如,服务提供方终端140的服务请求方C可以使用服务提供方终端140接收由服务实际提供者D提供服务的服务请求(比如服务请求方C可以为自己雇用的服务提供方D接单),和/或来自服务器110的信息或指令。在一些实施例中,“服务请求方”和“服务请求方终端”可以互换使用,“服务提供方”和“服务提供方终端”可以互换使用。
在一些实施例中,服务请求方终端130可以包括移动设备、平板计算机、膝上型计算机、或机动车辆中的内置设备等,或其任意组合。在一些实施例中,移动设备可以包括智能家居设备、可穿戴设备、智能移动设备、虚拟现实设备、或增强现实设备等,或其任意组合。在一些实施例中,智能家居设备可以包括智能照明设备、智能电器设备的控制设备、智能监控设备、智能电视、智能摄像机、或对讲机等,或其任意组合。在一些实施例中,可穿戴设备可包括智能手环、智能鞋带、智能玻璃、智能头盔、智能手表、智能服装、智能背包、智能配件等、或其任何组合。在一些实施例中,智能移动设备可以包括智能手机、个人数字助理(PersonalDigital Assistant,PDA)、游戏设备、导航设备、或销售点(point of sale,POS)设备等,或其任意组合。在一些实施例中,虚拟现实设备和/或增强现实设备可以包括虚拟现实头盔、虚拟现实玻璃、虚拟现实贴片、增强现实头盔、增强现实玻璃、或增强现实贴片等,或其任意组合。例如,虚拟现实设备和/或增强现实设备可以包括各种虚拟现实产品等。在一些实施例中,机动车辆中的内置设备可以包括车载计算机、车载电视等。在一些实施例中,服务请求方终端130可以是具有用于定位服务请求方和/或服务请求方终端的位置的定位技术的设备。
在一些实施例中,服务提供方终端140可以是与服务请求方终端130 类似或相同的设备。在一些实施例中,服务提供方终端140可以是具有定位技术的设备,用于定位服务提供方和/或服务提供方终端的位置。在一些实施例中,服务请求方终端130和/或服务提供方终端140可以与其他定位设备通信以确定服务请求方、服务请求方终端130、服务提供方、或服务提供方终端140、或其任意组合的位置。在一些实施例中,服务请求方终端 130和/或服务提供方终端140可以将定位信息发送给服务器110。
数据库150可以存储数据和/或指令。在一些实施例中,数据库150可以存储从服务请求方终端130和/或服务提供方终端140获得的数据。在一些实施例中,数据库150可以存储在本申请中描述的示例性方法的数据和/ 或指令。在一些实施例中,数据库150可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(Read-Only Memory,ROM)等,或其任意组合。作为举例,大容量存储器可以包括磁盘、光盘、固态驱动器等;可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等;易失性读写存储器可以包括随机存取存储器(Random Access Memory,RAM);RAM可以包括动态RAM(Dynamic RandomAccess Memory,DRAM),双倍数据速率同步动态RAM(Double Date-Rate Synchronous RAM,DDR SDRAM);静态RAM(Static Random-Access Memory,SRAM),晶闸管RAM(Thyristor-Based Random Access Memory, T-RAM)和零电容器RAM(Zero-RAM)等。作为举例,ROM可以包括掩模ROM(Mask Read-Only Memory,MROM)、可编程ROM(Programmable Read-OnlyMemory,PROM)、可擦除可编程ROM(Programmable Erasable Read-only Memory,PEROM)、电可擦除可编程ROM(Electrically Erasable Programmable read only memory,EEPROM)、光盘ROM(CD-ROM)、以及数字通用磁盘ROM等。在一些实施例中,数据库150可以在云平台上实现。仅作为示例,云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云或者其它类似的等,或其任意组合。
与上述方法相对应的,本申请还提供了一种服务方式确定装置,包括:
第一获取模块,用于获取服务请求方的历史订单信息;
第一输入模块,用于将服务请求方的历史订单信息输入到预先训练的偏好改变度确定模型中,得到服务请求方针对目标服务类型的偏好改变度;
第一确定模块,用于根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定服务请求方的服务方式。
在一些实施例中,第一确定模块,包括:
第一获取单元,用于获取服务请求方针对目标服务类型的偏好改变原因;
第一确定单元,用于根据服务请求方针对偏好改变度和偏好改变原因,确定服务请求方的服务方式。
在一些实施例中,第一获取单元,包括:
第一获取子单元,用于获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
第一确定子单元,用于根据至少一种历史订单信息的变化情况,确定服务请求方的偏好改变原因。
在一些实施例中,第一获取单元,包括:
第一发送子单元,用于向服务请求方发送针对偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息;
第二确定子单元,用于根据回复消息,确定偏好改变原因。
在一些实施例中,第一发送子单元,包括:
第二获取子单元,用于获取服务请求方在过去的预定时间内,与目标服务类型相关的至少一种历史订单信息的变化情况;
第一生成子单元,用于根据至少一种历史订单信息的变化情况,生成针对偏好改变度的询问请求;
第二发送子单元,用于向服务请求方发送针对偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息。
在一些实施例中,第一确定模块,包括:
第二获取单元,用于获取目标服务类型的服务资源量;
第二确定单元,用于根据服务请求方针对目标服务类型的偏好改变度和目标服务类型的服务资源量,确定服务请求方的服务方式。
在一些实施例中,第二确定单元,包括:
第三获取子单元,用于获取目标服务类型的服务资源量和其他服务类型的服务资源量的差别;
第三确定子单元,用于根据服务请求方针对目标服务类型的偏好改变度,以及目标服务类型的服务资源量和其他服务类型的服务资源量的差别,确定服务请求方的服务方式。
在一些实施例中,服务方式包括以下的任意一种或多种:
向服务请求方提供与偏好改变度相匹配的优惠券;
每隔预定时间向服务请求方发送服务优惠提示信息;
调整服务请求方在目标服务类型下的排队优先级;
调整服务请求方在目标服务类型下的服务流程。
在一些实施例中,偏好改变度确定模型是通过如下模块训练得到的:
第二获取模块,用于获取训练样本;训练样本包括样本服务请求方的历史订单信息和训练样本的类型;
第一使用模块,用于使用训练样本对偏好改变度确定模型进行训练。
在一些实施例中,训练样本的类型是通过如下模块确定的:
计算模块,用于计算样本服务请求方在第一历史时间段内发起指定类型的服务订单的第一数量占比和在第二历史时间段内发起指定类型的服务订单的第二数量占比;第一历史时间段早于第二历史时间段;
第一确定模块,用于根据第一数量占比和第二数量占比的差值,确定训练样本的类型。
在一些实施例中,第二获取模块,包括:
第三获取单元,用于获取样本服务请求方的活跃度;活跃度是根据以下任意一个或多个信息确定的:服务请求方下达的服务订单的数量、服务请求方下达的服务订单的类型数量和服务请求方下达服务订单的频率;
第三确定单元,若样本服务请求方的活跃度超过预定阈值,则用于将样本服务请求方在预定的历史时间段内的产生的历史订单信息和训练样本的类型作为训练样本。
在一些实施例中,历史订单信息包括以下的任意一种或多种:
用户属性信息、服务订单信息、服务场景信息、服务优惠信息。
与上述方法相对应的,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如服务方式确定方法的步骤。
如图5所示,为本申请实施例所提供的电子设备示意图,该电子设备1000包括:处理器1001、存储器1002和总线1003,存储器1002存储有执行指令,当电子设备运行时,处理器1001与存储器1002之间通过总线1003 通信,处理器1001执行存储器1002中存储的服务方式确定方法的步骤。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的服务器、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM, Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。

Claims (26)

1.一种服务方式确定方法,其特征在于,包括:
获取服务请求方的历史订单信息;
将所述服务请求方的历史订单信息输入到预先训练的偏好改变度确定模型中,得到所述服务请求方针对目标服务类型的偏好改变度;
根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定所述服务请求方的服务方式。
2.根据权利要求1所述的方法,其特征在于,根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定所述服务请求方的服务方式,包括:
获取服务请求方针对目标服务类型的偏好改变原因;
根据服务请求方针对所述偏好改变度和所述偏好改变原因,确定服务请求方的服务方式。
3.根据权利要求2所述的方法,其特征在于,获取服务请求方针对目标服务类型的偏好改变原因,包括:
获取服务请求方在过去的预定时间内,与所述目标服务类型相关的至少一种历史订单信息的变化情况;
根据所述至少一种历史订单信息的变化情况,确定服务请求方的偏好改变原因。
4.根据权利要求2所述的方法,其特征在于,获取服务请求方针对目标服务类型的偏好改变原因,包括:
向服务请求方发送针对所述偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息;
根据所述回复消息,确定偏好改变原因。
5.根据权利要求4所述的方法,其特征在于,向服务请求方发送针对所述偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息,包括:
获取服务请求方在过去的预定时间内,与所述目标服务类型相关的至少一种历史订单信息的变化情况;
根据所述至少一种历史订单信息的变化情况,生成针对所述偏好改变度的询问请求;
向服务请求方发送针对所述偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息。
6.根据权利要求1所述的方法,其特征在于,根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定所述服务请求方的服务方式,包括:
获取所述目标服务类型的服务资源量;
根据服务请求方针对目标服务类型的偏好改变度和所述目标服务类型的服务资源量,确定服务请求方的服务方式。
7.根据权利要求6所述的方法,其特征在于,根据服务请求方针对目标服务类型的偏好改变度和所述目标服务类型的服务资源量,确定服务请求方的服务方式,包括:
获取目标服务类型的服务资源量和其他服务类型的服务资源量的差别;
根据服务请求方针对目标服务类型的偏好改变度,以及目标服务类型的服务资源量和其他服务类型的服务资源量的差别,确定服务请求方的服务方式。
8.根据权利要求1所述的方法,其特征在于,服务方式包括以下的任意一种或多种:
向服务请求方提供与偏好改变度相匹配的优惠券;
每隔预定时间向服务请求方发送服务优惠提示信息;
调整服务请求方在目标服务类型下的排队优先级;
调整服务请求方在目标服务类型下的服务流程。
9.根据权利要求1所述的方法,其特征在于,偏好改变度确定模型是按照如下方式训练得到的:
获取训练样本;所述训练样本包括样本服务请求方的历史订单信息和训练样本的类型;
使用训练样本对偏好改变度确定模型进行训练。
10.根据权利要求9所述的方法,其特征在于,训练样本的类型是通过如下步骤确定的:
计算样本服务请求方在第一历史时间段内发起指定类型的服务订单的第一数量占比和在第二历史时间段内发起指定类型的服务订单的第二数量占比;第一历史时间段早于第二历史时间段;
根据第一数量占比和第二数量占比的差值,确定训练样本的类型。
11.根据权利要求9所述的方法,其特征在于,获取训练样本,包括:
获取样本服务请求方的活跃度;所述活跃度是根据以下任意一个或多个信息确定的:服务请求方下达的服务订单的数量、服务请求方下达的服务订单的类型数量和服务请求方下达服务订单的频率;
若所述样本服务请求方的活跃度超过预定阈值,则将样本服务请求方在预定的历史时间段内的产生的历史订单信息和训练样本的类型作为训练样本。
12.根据权利要求1所述的方法,其特征在于,历史订单信息包括以下的任意一种或多种:
用户属性信息、服务订单信息、服务场景信息、服务优惠信息。
13.一种服务方式确定装置,其特征在于,包括:
第一获取模块,用于获取服务请求方的历史订单信息;
第一输入模块,用于将所述服务请求方的历史订单信息输入到预先训练的偏好改变度确定模型中,得到所述服务请求方针对目标服务类型的偏好改变度;
第一确定模块,用于根据服务请求方针对目标服务类型的偏好改变度和服务方式的对应关系,确定所述服务请求方的服务方式。
14.根据权利要求13所述的装置,其特征在于,第一确定模块,包括:
第一获取单元,用于获取服务请求方针对目标服务类型的偏好改变原因;
第一确定单元,用于根据服务请求方针对所述偏好改变度和所述偏好改变原因,确定服务请求方的服务方式。
15.根据权利要求14所述的装置,其特征在于,第一获取单元,包括:
第一获取子单元,用于获取服务请求方在过去的预定时间内,与所述目标服务类型相关的至少一种历史订单信息的变化情况;
第一确定子单元,用于根据所述至少一种历史订单信息的变化情况,确定服务请求方的偏好改变原因。
16.根据权利要求14所述的装置,其特征在于,第一获取单元,包括:
第一发送子单元,用于向服务请求方发送针对所述偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息;
第二确定子单元,用于根据所述回复消息,确定偏好改变原因。
17.根据权利要求16所述的装置,其特征在于,第一发送子单元,包括:
第二获取子单元,用于获取服务请求方在过去的预定时间内,与所述目标服务类型相关的至少一种历史订单信息的变化情况;
第一生成子单元,用于根据所述至少一种历史订单信息的变化情况,生成针对所述偏好改变度的询问请求;
第二发送子单元,用于向服务请求方发送针对所述偏好改变度的询问请求,以使服务请求方返回针对询问请求所生成的回复消息。
18.根据权利要求13所述的装置,其特征在于,第一确定模块,包括:
第二获取单元,用于获取所述目标服务类型的服务资源量;
第二确定单元,用于根据服务请求方针对目标服务类型的偏好改变度和所述目标服务类型的服务资源量,确定服务请求方的服务方式。
19.根据权利要求18所述的装置,其特征在于,第二确定单元,包括:
第三获取子单元,用于获取目标服务类型的服务资源量和其他服务类型的服务资源量的差别;
第三确定子单元,用于根据服务请求方针对目标服务类型的偏好改变度,以及目标服务类型的服务资源量和其他服务类型的服务资源量的差别,确定服务请求方的服务方式。
20.根据权利要求13所述的装置,其特征在于,服务方式包括以下的任意一种或多种:
向服务请求方提供与偏好改变度相匹配的优惠券;
每隔预定时间向服务请求方发送服务优惠提示信息;
调整服务请求方在目标服务类型下的排队优先级;
调整服务请求方在目标服务类型下的服务流程。
21.根据权利要求13所述的装置,其特征在于,偏好改变度确定模型是通过如下模块训练得到的:
第二获取模块,用于获取训练样本;所述训练样本包括样本服务请求方的历史订单信息和训练样本的类型;
第一使用模块,用于使用训练样本对偏好改变度确定模型进行训练。
22.根据权利要求21所述的装置,其特征在于,训练样本的类型是通过如下模块确定的:
计算模块,用于计算样本服务请求方在第一历史时间段内发起指定类型的服务订单的第一数量占比和在第二历史时间段内发起指定类型的服务订单的第二数量占比;第一历史时间段早于第二历史时间段;
第一确定模块,用于根据第一数量占比和第二数量占比的差值,确定训练样本的类型。
23.根据权利要求21所述的装置,其特征在于,第二获取模块,包括:
第三获取单元,用于获取样本服务请求方的活跃度;所述活跃度是根据以下任意一个或多个信息确定的:服务请求方下达的服务订单的数量、服务请求方下达的服务订单的类型数量和服务请求方下达服务订单的频率;
第三确定单元,若所述样本服务请求方的活跃度超过预定阈值,则用于将样本服务请求方在预定的历史时间段内的产生的历史订单信息和训练样本的类型作为训练样本。
24.根据权利要求13所述的装置,其特征在于,历史订单信息包括以下的任意一种或多种:
用户属性信息、服务订单信息、服务场景信息、服务优惠信息。
25.一种电子设备,其特征在于,包括:处理器、存储介质和总线,所述存储介质存储有所述处理器可执行的机器可读指令,当电子设备运行时,所述处理器与所述存储介质之间通过总线通信,所述处理器执行所述机器可读指令,以执行时执行如权利要求1至12任一所述的一种服务方式确定方法的步骤。
26.一种计算机可读存储介质,其特征在于,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行如权利要求1至12任一所述的一种服务方式确定方法的步骤。
CN201811519939.3A 2018-12-12 2018-12-12 服务方式确定方法、装置、电子设备和存储介质 Active CN111311295B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201811519939.3A CN111311295B (zh) 2018-12-12 2018-12-12 服务方式确定方法、装置、电子设备和存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201811519939.3A CN111311295B (zh) 2018-12-12 2018-12-12 服务方式确定方法、装置、电子设备和存储介质

Publications (2)

Publication Number Publication Date
CN111311295A true CN111311295A (zh) 2020-06-19
CN111311295B CN111311295B (zh) 2023-10-13

Family

ID=71148051

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201811519939.3A Active CN111311295B (zh) 2018-12-12 2018-12-12 服务方式确定方法、装置、电子设备和存储介质

Country Status (1)

Country Link
CN (1) CN111311295B (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112036738A (zh) * 2020-08-28 2020-12-04 中国建设银行股份有限公司 服务订单分配方法、装置、电子设备和存储介质
CN112115351A (zh) * 2020-08-27 2020-12-22 长沙市到家悠享网络科技有限公司 服务方法、服务器、终端和介质
CN112256852A (zh) * 2020-10-28 2021-01-22 北京软通智慧城市科技有限公司 一种景区评论数据处理方法、装置、电子设备及存储介质
CN113344381A (zh) * 2021-06-04 2021-09-03 哈尔滨商业大学 任务完成质量的激励方法及装置、电子设备和存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101140582A (zh) * 2007-09-27 2008-03-12 中兴通讯股份有限公司 用户偏好生成系统和方法
CN103617540A (zh) * 2013-10-17 2014-03-05 浙江大学 一种追踪用户兴趣变化的电子商务推荐方法
CN105975613A (zh) * 2016-05-19 2016-09-28 国网重庆市电力公司客户服务中心 基于历史访问数据的服务渠道推荐方法、装置及系统
CN106447074A (zh) * 2016-12-30 2017-02-22 北京东方车云信息技术有限公司 一种将订单信息推送给司机客户端的方法、装置及系统
CN107038620A (zh) * 2017-02-15 2017-08-11 阿里巴巴集团控股有限公司 基于用户打车偏好的信息推送及装置
CN107862002A (zh) * 2017-10-20 2018-03-30 四川朗骏文化传播有限公司 一种个性化推荐系统
CN108629504A (zh) * 2018-05-02 2018-10-09 北京嘀嘀无限科技发展有限公司 为用户提供出行服务的方法及装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101140582A (zh) * 2007-09-27 2008-03-12 中兴通讯股份有限公司 用户偏好生成系统和方法
CN103617540A (zh) * 2013-10-17 2014-03-05 浙江大学 一种追踪用户兴趣变化的电子商务推荐方法
CN105975613A (zh) * 2016-05-19 2016-09-28 国网重庆市电力公司客户服务中心 基于历史访问数据的服务渠道推荐方法、装置及系统
CN106447074A (zh) * 2016-12-30 2017-02-22 北京东方车云信息技术有限公司 一种将订单信息推送给司机客户端的方法、装置及系统
CN107038620A (zh) * 2017-02-15 2017-08-11 阿里巴巴集团控股有限公司 基于用户打车偏好的信息推送及装置
CN107862002A (zh) * 2017-10-20 2018-03-30 四川朗骏文化传播有限公司 一种个性化推荐系统
CN108629504A (zh) * 2018-05-02 2018-10-09 北京嘀嘀无限科技发展有限公司 为用户提供出行服务的方法及装置

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112115351A (zh) * 2020-08-27 2020-12-22 长沙市到家悠享网络科技有限公司 服务方法、服务器、终端和介质
CN112036738A (zh) * 2020-08-28 2020-12-04 中国建设银行股份有限公司 服务订单分配方法、装置、电子设备和存储介质
CN112256852A (zh) * 2020-10-28 2021-01-22 北京软通智慧城市科技有限公司 一种景区评论数据处理方法、装置、电子设备及存储介质
CN113344381A (zh) * 2021-06-04 2021-09-03 哈尔滨商业大学 任务完成质量的激励方法及装置、电子设备和存储介质

Also Published As

Publication number Publication date
CN111311295B (zh) 2023-10-13

Similar Documents

Publication Publication Date Title
US11488277B2 (en) Personalizing ride experience based on contextual ride usage data
US20210232984A1 (en) Order allocation system and method
CN111311295A (zh) 服务方式确定方法、装置、电子设备和存储介质
JP6867504B2 (ja) オンデマンドサービスのための乗り物を割り当てるシステム及び方法
US20180174265A1 (en) Systems and methods for determining a target vehicle/provider
TWI722302B (zh) 用於運輸能力調度的系統和方法
US20180240045A1 (en) Systems and methods for allocating sharable orders
RU2018126467A (ru) Способ и система для индивидуализированных услуг по требованию
CN110869953A (zh) 推荐交通出行服务的系统和方法
CN110741402B (zh) 用于运力调度的系统和方法
US20180336610A1 (en) Network system with scheduled breaks
TW202009807A (zh) 用於分配訂單的系統和方法
CN109416823A (zh) 用于确定司机安全分的系统和方法
CN110288418B (zh) 汽车共享系统、方法和存储程序的非瞬态存储介质
US20210042817A1 (en) Methods and systems for order allocation
CN111433795A (zh) 一种确定线上到线下服务的预估到达时间的系统和方法
CN112215448A (zh) 分配客服的方法和装置
KR102390924B1 (ko) 대리운전 중개 서비스 관련 마일리지 관리 장치 및 그 관리 방법
US20210201393A1 (en) System and method for bidding-based ridesharing
CN110245762A (zh) 兴趣预约管理的通信方法和移动终端以及服务器和系统
CN111144603A (zh) 一种服务信息推送方法、装置、电子设备和存储介质
WO2021186211A1 (en) Methods, systems, and devices for managing service requests and pricing policies for services provided by service providers to users
JP7327241B2 (ja) 情報処理装置、プログラム、及び評価方法
CN111753386B (zh) 一种数据处理方法及装置
CN111242711A (zh) 信息提示方法、装置、电子设备和存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant