行程确定方法、系统、设备及介质与流程

1.本发明涉及计算机领域，尤其涉及一种行程确定方法、系统、设备及介质。


背景技术：

2.在ota(在线旅游)以及tmc(差旅管理)行业中，相对于电商等高频次消费行业，交通出行和住宿类产品的低频次消费特征决定了很难通过历史订单数据构建相对完善的用户行为。同时，对多数企业而言，在较长周期内，商务出行的城市、省份相对固定，同行业、同公司行程相似度高。此外，有的客户仅有部分用户在平台下单，其行程有多种组合的可能，对于经常出差的客户，两次出差时间间隔小，难以将单次出差的行程进行识别，无法对客户的订单使用情况进行分析，无法提升产品购买转化率，也无法实现对用户推荐同一个行程中的相关产品。


技术实现要素：

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.图1为实施例1中的行程确定方法的流程示意图。
33.图2为实施例1中的行程确定方法的另一种流程示意图。
34.图3为实施例1中的行程确定方法的另一种流程示意图。
35.图4为实施例2中的行程确定系统的一种结构示意图。
36.图5为实施例3中提供的一种电子设备的结构示意图。
具体实施方式
37.下面通过实施例的方式进一步说明本发明，但并不因此将本发明限制在的实施例范围之中。
38.实施例1
39.请参见图1，本实施例提供一种行程确定方法，包括以下步骤：
40.s1、获取目标用户的历史订单，并根据历史订单的起始时间和结束时间将每个历史订单拆分为两个子历史订单；
41.请参见表1，表1中展示了获取用户的历史订单，并根据历史订单的起始时间以及结束时间将历史订单拆分为两个子历史订单。表1为如下所示：
42.表1
[0043][0044][0045]
s2、将子历史订单按照时间进行排序；
[0046]
在本实施例中，对表1中的历史订单进行排序，具体请参见表2；表2中的行程城市也就是上文中所提及到的订单对应的地址。
[0047]
表2
[0048]
用户标识行程时间行程城市
6661月1日12时深圳6661月1日14时上海6661月1日15时上海6661月2日12时上海6661月2日18时上海6661月2日20时深圳
[0049]
s3、根据目标订单对应的地址与前一订单对应的地址，以及目标订单与前一订单的间隔时间确定目标订单与前一订单是否属于同一个行程；
[0050]
其中，目标订单为子历史订单中的任一订单。
[0051]
在本实施例中，能够通过历史订单确定用户的行程，对客户的订单使用情况进行分析，提升产品购买转化率，还可以实现对用户推荐同一个行程中的相关产品。
[0052]
具体地，参见图2，目标订单的类型可以为出行订单；
[0053]
上述步骤s3具体包括：
[0054]
s31、若目标订单的出发地与前一订单的目的地或者酒店所在地相同，且目标订单与前一订单的间隔时间段小于第一时间段，则确定目标订单与前一订单属于同一个行程。
[0055]
比如，目标订单的出行地为上海，前一订单的目的地或者酒店所在地也为上海，此时目标订单以及前一订单的间隔时间小于第一时间段(例如30天)，则确定目标订单与前一订单属于同一个行程。
[0056]
具体地，行程确定方法可以包括步骤：获取与目标用户对应的目标城市；
[0057]
上述步骤s3具体包括：
[0058]
s32、若目标订单的出发地与前一订单的目的地或者酒店所在地不同，且前一订单的目的地或者酒店所在地与目标城市不同，且目标订单与前一订单的间隔时间段小于第三时间段，则确定目标订单与前一订单属于同一个行程。
[0059]
对于现实场景中，用户在同一行程中一般会在多个平台进行下单。例如，某用户在平台1下订单1、2、3、5；在平台2下订单4。但是平台1无法获取该用户该行程的全部订单数据，此时可以通过获取目标城市，并判断订单3、5间隔时间段是否小于第三时间段(例如1.5天)，就确定订单3以及订单5是否属于同一个行程。具体地，例如，目标城市是上海，订单5的出发地为上海。订单3为出行订单，目的地为南京(与目标城市不同)。当订单3以及订单5之间的时间间隔小于1.5天，就可以将订单5以及订单3确定为属于同一个行程。又例如，目标城市是上海，订单5的出发地为上海。订单3为酒店订单，酒店所在地为南京(与目标城市不同)。当订单3以及订单5之间的时间间隔小于第三时间段(如1.5天)，也可以确定订单3以及订单5属于同一个行程。
[0060]
具体地，请参见图3，目标订单的类型可以为酒店订单；
[0061]
上述步骤s3具体包括：
[0062]
s33、若目标订单的酒店所在地与前一订单的目的地或者酒店所在地相同，且目标订单与前一订单的间隔时间段小于第二时间段，则确定目标订单与前一订单属于同一个行程。
[0063]
例如，目标城市是上海，第二时间段为1天。目标订单的时间是1月1号12点，该目标订单的酒店所在地为上海。上一订单的时间是1月1日3点，该订单对应的地址也为上海。此
时与上一订单的时间间隔小于第二时间段，那么就可以将目标订单以及前一订单确定为属于同一个行程。
[0064]
具体地，还包括以下步骤：获取与用户对应的目标城市；
[0065]
根据目标订单对应的地址与前一订单对应的地址，以及目标订单与前一订单的间隔时间确定目标订单与前一订单是否属于同一个行程的步骤具体包括：
[0066]
s34、若目标订单的酒店所在地与前一订单的目的地或者酒店所在地不同，且目标订单的酒店所在地的省份与前一订单的目的地或者酒店所在地的省份相同，且目标订单与前一订单的间隔时间段小于第四时间段，则确定目标订单与前一订单属于同一个行程。
[0067]
本实施例中，很多出行中短途出行订单在平台上是无法实现预定的。例如，第四时间段为1.5天，订单1的对应的地址为杭州，时间为1月1日12点；订单2的酒店所在地绍兴，时间为1月2日12点，由于当前订单的省份都是浙江省，且订单2和订单1的间隔时间小于1.5天，那么就可以确定订单1以及订单2属于同一个行程。
[0068]
本实施例应用于短途旅行时，部分出行订单无法获取的情形。本实施例对于该情形就能够进行判断目标订单以及前一订单是否属于同一个行程。对于出行行程判断会更加准确。
[0069]
具体地，目标城市户的居住城市、历史订单中出现频次最多的城市或者用户的常住城市。
[0070]
在本实施例中，用户的居住城市判断具体为：对出行订单大于一定数量的用户，统计出行订单中出现城市的次数最多的城市，并排除酒店订单中出现的城市，在剩余城市中频次最高的城市作为用户的居住城市。
[0071]
获取用户的常住城市具体包括：根据用户的地理位置信息统计城市出现的频次，然后排除酒店订单中的酒店所在城市，在剩余城市中频次最高的城市作为常住城市。
[0072]
当历史订单中出现频次最多的城市作为目标城市的时候。用户可以包括：企业客户以及平台客户。企业客户的目标城市由客户经理填写，平台客户的目标城市由注册人自主填写(但是现实中，目标城市不是必填选项，故目标城市缺失的几率更大)。其中，当企业客户的目标城市缺失时，企业客户的目标城市为历史订单中出现次数最高的城市。平台客户能够根据首次注册时网络ip地址反查所在城市。当网络ip地址缺失时，再获取历史订单中出现次数最高的城市。
[0073]
在本实施例中，居住城市、常住城市以及频次最多的城市三者还可以设置优先级。例如，优先级可以可设置为：居住城市的优先级＞常住城市的优先级＞频次最多的城市的优先级(即先获取居住城市，当居住城市无法获取，则再获取常住城市，当常住城市无法获取，再获取频次最多城市)。通过该优先级的设置，获取的目标城市更加精准。
[0074]
在本实施例中，若用户的目标城市是缺失的，则可以通过各个订单的数据，获取目标数据。并且设置多个优先级，使得获取目标城市更加精准。
[0075]
具体地，行程确定方法可以包括以下步骤：
[0076]
在目标订单与前一订单属于同一个行程的情况下；
[0077]
s4、若目标订单对应的地址与前一订单对应的地址不同，则确定目标订单与前一订单属于不同的子行程。
[0078]
在本实施例中，当目标订单对应的地址和前一订单对应的地址相同，就将目标订
单以及前一订单两者确定为一个子行程。实际使用中，一个行程中包括各个子行程，且各个子行程连接为一个行程。例如，没有子行程缺失的行程应该是：子行程1：上海-杭州、子行程2：杭州-南京、子行程3：南京-北京、子行程4：北京-上海。但是，有缺失的子行程的行程为：子行程1：上海-杭州、子行程3：南京-北京、子行程4：北京-上海。那么就可以确定应当出现的子行程2是缺失的(也即目标订单与前一订单属于不同的子行程)。本实施例可以确定缺失的子行程，业务部门可以根据缺失的子行程进行运营决策(如提供缺失的子行程的优惠票价，使得用户在平台订缺失的子行程的票，使得提高市场占用率)。
[0079]
在本实施例中，对于子行程的判断需要符合mece规则(相互独立，完全穷尽的规则)。
[0080]
此外，在本实施例中，获取目标用户的历史订单可以通过用户标识获取用户的历史订单。用户标识可以是用户id、常用用户id或者“客户员工id+姓名信息”。
[0081]
其中，用户id可根据用户的身份证、护照等信息进行关联。常用用户id能够根据用户的姓名信息对应匹配到该用户的常用用户id，此时用户id可以使用“特定前缀+常用用户id”作为用户标识。但是，若该用户没有常用用户id，那么就可以使用“客户员工id+姓名信息”作为该用户的用户标识。在用户在平台注册账号的时候，需要填写用户的姓名信息。当用户有问题需要找平台的咨询，平台的员工就会与该用户进行对接并提供相应的服务。而客户员工id就是与该用户服务过的员工的员工id。
[0082]
在实际使用的过程中，历史订单通常包括：产品类型、订单id、预订日期、子订单序号、出行人唯一标识、预订人id、公司id、出行人工作城市、出行人工作省份、产品使用开始时间、产品使用结束时间、产品使用开始城市、产品使用结束城市、产品使用开始省份、产品使用结束省份、一次行程id、当前行程开始日期、当前行程结束日期、当前行程出发城市名称、当前行程最终到达城市名称、一次行程子行程id、当前子行程开始日期、当前子行程结束日期、当前子行程城市名称等类型数据。
[0083]
实施例2
[0084]
请参见图4，本实施例提供一种行程确定系统，包括：
[0085]
获取模块201，用于获取目标用户的历史订单，并根据历史订单的起始时间和结束时间将每个历史订单拆分为两个子历史订单；
[0086]
排序模块202，用于将子历史订单按照时间进行排序；
[0087]
确定模块203，用于根据目标订单对应的地址与前一订单对应的地址，以及目标订单与前一订单的间隔时间确定目标订单与前一订单是否属于同一个行程；其中，目标订单为子历史订单中的任一订单。
[0088]
具体地，目标订单的类型可以为出行订单；
[0089]
确定模块203具体用于，在目标订单的出发地与前一订单的目的地或者酒店所在地相同，且目标订单与前一订单的间隔时间段小于第一时间段的情况系，确定目标订单与前一订单属于同一个行程。
[0090]
具体地，获取模块201，可以用于获取与目标用户对应的目标城市；
[0091]
确定模块203具体用于，在目标订单的出发地与前一订单的目的地或者酒店所在地不同，且前一订单的目的地或者酒店所在地与目标城市不同，且目标订单与前一订单的间隔时间段小于第三时间段的情况下，确定目标订单与前一订单属于同一个行程。
[0092]
具体地，目标订单的类型可以为酒店订单；
[0093]
确定模块203具体用于，在目标订单的酒店所在地与前一订单的目的地或者酒店所在地相同，且目标订单与前一订单的间隔时间段小于第二时间段的情况下，确定目标订单与前一订单属于同一个行程。
[0094]
具体地，获取模块201，可以获取与用户对应的目标城市；
[0095]
确定模块203具体用于，在目标订单的酒店所在地与前一订单的目的地或者酒店所在地不同，且目标订单的酒店所在地的省份与前一订单的目的地或者酒店所在地的省份相同，且目标订单与前一订单的间隔时间段小于第四时间段的情况下，确定目标订单与前一订单属于同一个行程。
[0096]
具体地，目标城市可以为用户的居住城市、历史订单中出现频次最多的城市或者用户的常住城市。
[0097]
本实施例中的行程确定系统与实施例1中的行程确定方法的原理相同，故在此不再赘述。
[0098]
在本实施例中，用户的居住城市判断具体为：对出行订单大于一定数量的用户，统计出行订单中出现城市的次数最多的城市，并排除酒店订单中出现的城市，在剩余城市中频次最高的城市作为用户的居住城市。
[0099]
获取用户的常住城市具体包括：根据用户的地理位置信息统计城市出现的频次，然后排除酒店订单中的酒店所在城市，在剩余城市中频次最高的城市作为常住城市。
[0100]
当历史订单中出现频次最多的城市作为目标城市的时候。用户可以包括：企业客户以及平台客户。企业客户的目标城市由客户经理填写，平台客户的目标城市由注册人自主填写。其中，当企业客户的目标城市缺失时，企业客户的目标城市为历史订单中出现次数最高的城市。平台客户能够根据首次注册时网络ip地址反查所在城市。当ip缺失时，再获取历史订单中出现次数最高的城市。
[0101]
在本实施例中，居住城市、常住城市以及频次最多的城市三者还可以设置优先级。优先级可以可设置为：居住城市的优先级＞常住城市的优先级＞频次最多的城市的优先级。
[0102]
具体地，在目标订单与前一订单属于同一个行程的情况下，若目标订单对应的地址与前一订单对应的地址不同，则确定模块203，可以用于确定目标订单与前一订单属于不同的子行程。
[0103]
此外，在本实施例中，获取目标用户的历史订单可以通过用户标识获取用户的历史订单。用户标识可以是用户id、常用用户id或者“客户员工id+姓名信息”。
[0104]
其中，用户id可根据用户的身份证、护照等信息进行关联。常用用户id能够根据用户的姓名信息对应匹配到该用户的常用用户id，此时用户id可以使用“特定前缀+常用用户id”作为用户标识。但是，若该用户没有常用用户id，那么就可以使用“客户员工id+姓名信息”作为该用户的用户标识。其中，客户员工id是与该用户服务过的员工的员工id。
[0105]
实施例3
[0106]
图5为本实施例提供的一种电子设备的结构示意图。所述电子设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现实施例1的行程确定方法的步骤。图5显示的电子设备30仅仅是一个示例，不应对本发明
实施例的功能和使用范围带来任何限制。
[0107]
如图5所示，电子设备30可以以通用计算设备的形式表现，例如其可以为服务器设备。电子设备30的组件可以包括但不限于：上述至少一个处理器31、上述至少一个存储器32、连接不同系统组件(包括存储器32和处理器31)的总线33。
[0108]
总线33包括数据总线、地址总线和控制总线。
[0109]
存储器32可以包括易失性存储器，例如随机存取存储器(ram)321和/或高速缓存存储器322，还可以进一步包括只读存储器(rom)323。
[0110]
存储器32还可以包括具有一组(至少一个)程序模块324的程序/实用工具325，这样的程序模块324包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
[0111]
处理器31通过运行存储在存储器32中的计算机程序，从而执行各种功能应用以及数据处理，例如本发明实施例1的行程确定方法的步骤。
[0112]
电子设备30也可以与一个或多个外部设备34(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(i/o)接口35进行。并且，模型生成的设备30还可以通过网络适配器36与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器36通过总线33与模型生成的设备30的其它模块通信。应当明白，尽管图中未示出，可以结合模型生成的设备30使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、raid(磁盘阵列)系统、磁带驱动器以及数据备份存储系统等。
[0113]
应当注意，尽管在上文详细描述中提及了电子设备的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
[0114]
实施例4
[0115]
本实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现实施例1的行程确定方法的步骤。
[0116]
其中，可读存储介质可以采用的更具体可以包括但不限于：便携式盘、硬盘、随机存取存储器、只读存储器、可擦拭可编程只读存储器、光存储器件、磁存储器件或上述的任意合适的组合。
[0117]
在可能的实施方式中，本发明还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行实现实施例1的行程确定方法的步骤。
[0118]
其中，可以以一种或多种程序设计语言的任意组合来编写用于执行本发明的程序代码，所述程序代码可以完全地在用户设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户设备上部分在远程设备上执行或完全在远程设备上执行
[0119]
虽然以上描述了本发明的具体实施方式，但是本领域的技术人员应当理解，这仅是举例说明，本发明的保护范围是由所附权利要求书限定的。本领域的技术人员在不背离本发明的原理和实质的前提下，可以对这些实施方式做出多种变更或修改，但这些变更和修改均落入本发明的保护范围。