订单标签添加方法及装置与流程

1.本公开的实施例涉及订单处理技术领域，尤其涉及一种订单标签添加方法及装置。


背景技术：

2.随着经济水平的不断提升，外卖订单已经成为现代人生活的方式之一，大量商家聚集在订单平台为用户提供了丰富的选择，这也会造成用户有更多的选择困难，然而在这个订单履约的核心节点，现有的外卖平台并没有做过针对性的事情帮助用户更快更好的选择商品，这种情况给用户造成较差的体验。
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.订单评分获取单元，用于根据所述目标配送时长，对所述业务订单进行评分处理，得到所述业务订单的评分值。
33.可选地，所述配送时长确定单元包括：
34.第一配送时长获取子单元，用于根据所述业务订单中每个业务对象配送至所述用户对应的配送地址的第一历史配送时长，计算得到所述第一历史配送时长的第一平均值，并将该第一平均值作为所述目标配送时长；
35.第二配送时长获取子单元，用于获取所述业务订单中每个业务对象在距离当前时间为预设时长内的第二历史配送时长，计算得到所述第二历史配送时长的第二平均值，并将该第二平均值作为所述目标配送时长；
36.第三配送时长获取子单元，用于根据所述业务订单中每个业务对象配送至所述用户对应的配送地址的第三历史配送时长，获取所述第三历史配送时长中的最大值，并将该最大值作为所述目标配送时长。
37.可选地，所述目标订单确定模块包括：
38.初始业务订单获取单元，用于获取所述业务订单中评分维度相同的初始业务订单；
39.目标业务订单获取单元，用于从所述初始业务订单中筛选出评分值最大的业务订单，并将所述评分值最大的业务订单作为所述目标业务订单。
40.可选地，所述装置还包括：
41.订单评分值获取模块，用于在接收到所述用户对所述业务订单的显示操作之后，根据预设评分策略，对所述业务订单的评分值进行二次评分处理，得到所述业务订单对应的订单评分值；
42.订单评分显示模块，用于显示订单显示页面，并将所述业务订单和所述订单评分值显示于所述订单显示页面。
43.根据本公开的实施例的第三方面，提供了一种电子设备，包括：
44.处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一项所述的订单标签添加方法。
45.根据本公开的实施例的第四方面，提供了一种可读存储介质，当所述存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述任一项所述的订单标签添加方法。
46.本公开的实施例提供了一种订单标签添加方法及装置，通过获取用户已选择的业务订单，根据业务订单的订单类型，确定业务订单对应的评分维度，根据评分维度对业务订单进行评分处理，得到业务订单的评分值；根据评分值，确定业务订单中的目标业务订单，为目标业务订单添加与评分维度关联的订单标签。本公开的实施例通过综合对比用户选择的多个订单，计算出每个订单的优势，通过打标签的方式可以向用户直观展示订单信息，能够辅助用户快速做出订单选择，提高了用户体验，且提升了订单平台的成单率和留存率。
附图说明
47.为了更清楚地说明本公开的实施例的技术方案，下面将对本公开的实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开的实施例的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
48.图1为本公开的实施例提供的一种订单标签添加方法的步骤流程图；
49.图2为本公开的实施例提供的另一种订单标签添加方法的步骤流程图；
50.图3为本公开的实施例提供的一种雷达图显示订单评分的示意图；
51.图4为本公开的实施例提供对另一种雷达图显示订单评分的示意图；
52.图5为本公开的实施例提供的一种订单标签添加装置的结构示意图；
53.图6为本公开的实施例提供的另一种订单标签添加装置的结构示意图。
具体实施方式
54.下面将结合本公开的实施例中的附图，对本公开的实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开的实施例一部分实施例，而不是全部的实施例。基于本公开的实施例中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本公开的实施例保护的范围。
55.实施例一
56.参照图1，示出了本公开的实施例提供的一种订单标签添加方法的步骤流程图，如图1所示，该订单标签添加方法具体可以包括如下步骤：
57.步骤101：获取用户已选择的业务订单。
58.本公开的实施例可以应用于结合预设维度对业务订单进行评分，并根据评分对目标业务订单添加预设维度对应的标签的场景中。
59.本实施例可以应用于订单平台，即以订单平台作为执行主语。
60.业务订单是指用户已经选择并添加于备选模块或购物车内的订单，在本示例中，业务订单可以为添加至购物车或者备选模块内的订单，例如，在某订单平台预先设置有购物车，在用户选择某个门店内的一个或多个商品时，可以将一个或多个商品加入到购物车内，该一个或多个商品即形成一个订单。
61.在需要对用户选择的业务订单添加订单标签时，可以获取用户已选择的业务订单。
62.在获取到用户已选择的业务订单之后，执行步骤102。
63.步骤102：根据所述业务订单的订单类型，确定所述业务订单对应的评分维度。
64.订单类型是指与业务订单内的业务对象关联的类型，例如，在业务订单内包含的业务对象为餐饮类对象(如饮料、菜品等)时，则该业务订单的订单类型为餐饮类型；在业务订单内包含的业务对象为花类(如玫瑰、牡丹等)时，则该业务订单的订单类型为鲜花类型等等。
65.评分维度是指用于对业务订单进行订单评分的维度，在实际应用中，评分维度可以为：配送时长维度、门店优惠维度、价格维度、健康指数维度等。
66.在获取到用户已选择的业务订单之后，可以获取业务订单的订单类型，并根据业务订单的订单类型，确定业务订单对应的评分维度，例如，在订单类型为餐饮类型时，业务订单的评分维度可以为配送时长维度、健康指数维度、门店优惠维度、价格维度等；在订单类型为鲜花类型时，业务订单的评分维度可以为配送时长维度、价格维度等等。
67.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
68.在根据业务订单的订单类型确定出业务订单对应的评分维度之后，执行步骤103。
69.步骤103：根据所述评分维度，对所述业务订单进行评分处理，得到所述业务订单的评分值。
70.在确定出业务订单对应的评分维度之后，可以根据评分维度对业务订单进行评分处理，以得到业务订单的评分值，在具体实现中，可以预先针对不同的评分维度，设置对应的评分策略，例如，评分维度以配送时长维度为例，针对配送时长为0～10分钟内的订单，可以设置对应的订单评分为15，11～20分钟内的订单，可以设置对应的订单评分为10，21～30分钟内的订单，可以设置对应的订单评分为5等。评分维度以健康指数维度为例，针对餐饮类订单，可以预先设置油炸类食品的评分为5，碳酸饮料等饮品的评分为10等等。
71.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本公开的实施例的唯一限制。
72.接下来，可以结合配送时长维度对评分过程进行如下详细描述。
73.在本公开的一种具体实现方式中，上述步骤103可以包括：
74.子步骤s1：在所述评分维度为配送时长维度的情况下，根据所述业务订单对应的历史配送时长，确定所述业务订单的目标配送时长。
75.在本实施例中，目标配送时长是指配送业务订单所需花费的时长。
76.在评分维度为配送时长维度的情况下，可以根据业务订单对应的历史配送时长，确定业务订单的目标配送时长，对于该过程可以分为以下三种情况进行描述。
77.1、根据业务订单中每个业务对象配送至用户对应的配送地址的第一历史配送时长，计算得到第一历史配送时长的第一平均值，并将该第一平均值作为目标配送时长，即根据用户收货地址，计算业务订单内每个商品配送到该地址的时间的平均值，例如a商品配送到该地点的历史配送时间为40min、50min、60min，则平均值为50min，该平均值作为该商品的配送时间；
78.2、获取业务订单中每个业务对象在距离当前时间为预设时长内的第二历史配送时长，计算得到第二历史配送时长的第二平均值，并将该第二平均值作为目标配送时长，具体地，可以根据不同门店的情况设置计算单品历史配送时间计算的时间段，比如计算一周内/一个月的单品历史配送时间，得到更加真实的时间；
79.3、根据业务订单中每个业务对象配送至用户对应的配送地址的第三历史配送时长，获取第三历史配送时长中的最大值，并将该最大值作为目标配送时长，即在一个订单内有多个单品时，可以取历史配送时间最长的单品时间作为目标配送时长等。
80.当然，在业务订单内某个单品没有历史配送时间时，可以使用所有时间的历史订单，若所有历史时间无订单，使用该门店所有商品的平均配送时间，若门店没有历史配送时间，则不添加标签，本示例对此种情况不做考虑。
81.在根据业务订单对应的历史配送时长确定出业务订单的目标配送时长之后，执行子步骤s2。
82.子步骤s2：根据所述目标配送时长，对所述业务订单进行评分处理，得到所述业务订单的评分值。
83.在获取到业务订单的目标配送时长之后，可以根据目标配送时长对业务订单进行评分处理，以得到业务订单的评分值，在实际应用中，可以预先针对不同的配送时长段设置对应的评分值，配送时长越长评分值越小，反之，配送时长越短则评分值越大。
84.当然，在具体实现中，一个业务订单可以对应于一种评分维度，也可以对应于多种评分维度，具体地，可以根据业务需求而定，本实施例对此不加以限制。
85.在本实施例中，还可以通过预设页面展示业务订单和评分维度的订单评分，可以给用户以直观感受，具体地，可以结合下述具体实现方式进行详细描述。
86.在本公开的另一种具体实现方式中，在上述步骤103之后，还可以包括：
87.步骤m1：在接收到所述用户对所述业务订单的显示操作之后，根据预设评分策略，对所述业务订单的评分值进行二次评分处理，得到所述业务订单对应的订单评分值。
88.在本实施例中，预设评分策略是指在订单显示页面显示业务订单和订单评分值进行二次评分的策略。
89.在接收到用户对业务订单的显示操作之后，可以根据预设评分策略对业务订单的评分值进行二次评分处理，以得到业务订单对应的订单评分值。
90.在对业务订单的评分值进行二次评分处理得到业务订单对应的订单评分值之后，
执行步骤m2。
91.步骤m2：显示订单显示页面，并将所述业务订单和所述订单评分值显示于所述订单显示页面。
92.在得到业务订单对应的订单评分值之后，可以显示订单显示页面，并将业务订单和订单评分值显示于订单显示页面。
93.在具体实现中，订单显示页面可以为雷达图显示页面，雷达图的是对比当前用户选择的订单，给出的评分并不是各个维度真实的评分，会根据真实评分通过一定方式转换成雷达图评分，强调对比结果的差异，雷达图可自定义评分进制，比如5分制，10分制，不同维度的评分进制有可能与雷达图，当多个订单评分不一致时会通过一定的自研算法做转换，评分转换策略可以为：雷达图评分
‑
＝单个维度评分/单个维度分数制
×
雷达图分数制，例如，配送评分是8.5分，配送评分制是10分制，雷达图分数制是5分制，则转换成雷达图分数为：(8.5/10)*5＝4.25分等。
94.使用雷达图显示业务订单和订单评分的效果可以如图3和图4所示，在雷达图上可以显示业务订单在每个评分维度下的评分，综合分析业务订单的利弊，从整体上给用户参考，帮助用户做出选择。
95.在根据评分维度对业务订单进行评分处理，得到业务订单的评分值之后，执行步骤104。
96.步骤104：根据所述评分值，确定所述业务订单中的目标业务订单。
97.目标业务订单是指从业务订单中筛选的需要打标签的业务订单。
98.在根据评分维度对业务订单进行评分处理得到业务订单的评分值之后，可以根据评分值确定出业务订单中的目标业务订单，在本示例中，可以根据单个评分维度，从业务订单中筛选出在单个评分维度下评分值最大的业务订单作为目标业务订单。
99.在根据评分值确定出业务订单中的目标业务订单之后，执行步骤105。
100.步骤105：为所述目标业务订单添加与所述评分维度关联的订单标签。
101.在确定出业务订单中的目标业务订单之后，可以为目标业务订单添加与评分维度关联的订单标签，例如，在根据配送时长维度确定的目标业务订单为订单1时，则为订单1添加配送速度较快的订单标签。在根据配送时长维度和门店评分维度确定的目标业务订单均为订单2时，则为订单2添加配送速度较快的订单标签和评分较高的订单标签等。
102.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
103.本公开的实施例通过综合对比用户选择的多个订单，计算出每个订单的优势，通过打标签的方式可以向用户直观展示订单信息，能够辅助用户快速做出订单选择。
104.本公开的实施例提供的订单标签添加方法，通过获取用户已选择的业务订单，根据业务订单的订单类型，确定业务订单对应的评分维度，根据评分维度对业务订单进行评分处理，得到业务订单的评分值；根据评分值，确定业务订单中的目标业务订单，为目标业务订单添加与评分维度关联的订单标签。本公开的实施例通过综合对比用户选择的多个订单，计算出每个订单的优势，通过打标签的方式可以向用户直观展示订单信息，能够辅助用户快速做出订单选择，提高了用户体验，且提升了订单平台的成单率和留存率。
105.实施例二
106.参照图2，示出了本公开的实施例提供的另一种订单标签添加方法的步骤流程图，如图2所示，该订单标签添加方法具体可以包括如下步骤：
107.步骤201：获取用户已选择的业务订单。
108.本公开的实施例可以应用于结合预设维度对业务订单进行评分，并根据评分对目标业务订单添加预设维度对应的标签的场景中。
109.本实施例可以应用于订单平台，即以订单平台作为执行主语。
110.业务订单是指用户已经选择并添加于备选模块或购物车内的订单，在本示例中，业务订单可以为添加至购物车或者备选模块内的订单，例如，在某订单平台预先设置有购物车，在用户选择某个门店内的一个或多个商品时，可以将一个或多个商品加入到购物车内，该一个或多个商品即形成一个订单。
111.在需要对用户选择的业务订单添加订单标签时，可以获取用户已选择的业务订单。
112.在获取到用户已选择的业务订单之后，执行步骤202。
113.步骤202：根据所述业务订单的订单类型，确定所述业务订单对应的评分维度。
114.订单类型是指与业务订单内的业务对象关联的类型，例如，在业务订单内包含的业务对象为餐饮类对象(如饮料、菜品等)时，则该业务订单的订单类型为餐饮类型；在业务订单内包含的业务对象为花类(如玫瑰、牡丹等)时，则该业务订单的订单类型为鲜花类型等等。
115.评分维度是指用于对业务订单进行订单评分的维度，在实际应用中，评分维度可以为：配送时长维度、门店优惠维度、价格维度、健康指数维度等。
116.在获取到用户已选择的业务订单之后，可以获取业务订单的订单类型，并根据业务订单的订单类型，确定业务订单对应的评分维度，例如，在订单类型为餐饮类型时，业务订单的评分维度可以为配送时长维度、健康指数维度、门店优惠维度、价格维度等；在订单类型为鲜花类型时，业务订单的评分维度可以为配送时长维度、价格维度等等。
117.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
118.在根据业务订单的订单类型确定出业务订单对应的评分维度之后，执行步骤203。
119.步骤203：根据所述评分维度，对所述业务订单进行评分处理，得到所述业务订单的评分值。
120.在确定出业务订单对应的评分维度之后，可以根据评分维度对业务订单进行评分处理，以得到业务订单的评分值，在具体实现中，可以预先针对不同的评分维度，设置对应的评分策略，例如，评分维度以配送时长维度为例，针对配送时长为0～10分钟内的订单，可以设置对应的订单评分为15，11～20分钟内的订单，可以设置对应的订单评分为10，21～30分钟内的订单，可以设置对应的订单评分为5等。评分维度以健康指数维度为例，针对餐饮类订单，可以预先设置油炸类食品的评分为5，碳酸饮料等饮品的评分为10等等。
121.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本公开的实施例的唯一限制。
122.接下来，可以结合配送时长维度对评分过程进行如下详细描述。
123.在本公开的一种具体实现方式中，上述步骤203可以包括：
124.子步骤n1：在所述评分维度为配送时长维度的情况下，根据所述业务订单对应的历史配送时长，确定所述业务订单的目标配送时长。
125.在本实施例中，目标配送时长是指配送业务订单所需花费的时长。
126.在评分维度为配送时长维度的情况下，可以根据业务订单对应的历史配送时长，确定业务订单的目标配送时长，对于该过程可以分为以下三种情况进行描述。
127.1、根据业务订单中每个业务对象配送至用户对应的配送地址的第一历史配送时长，计算得到第一历史配送时长的第一平均值，并将该第一平均值作为目标配送时长，即根据用户收货地址，计算业务订单内每个商品配送到该地址的时间的平均值，例如a商品配送到该地点的历史配送时间为40min、50min、60min，则平均值为50min，该平均值作为该商品的配送时间；
128.2、获取业务订单中每个业务对象在距离当前时间为预设时长内的第二历史配送时长，计算得到第二历史配送时长的第二平均值，并将该第二平均值作为目标配送时长，具体地，可以根据不同门店的情况设置计算单品历史配送时间计算的时间段，比如计算一周内/一个月的单品历史配送时间，得到更加真实的时间；
129.3、根据业务订单中每个业务对象配送至用户对应的配送地址的第三历史配送时长，获取第三历史配送时长中的最大值，并将该最大值作为目标配送时长，即在一个订单内有多个单品时，可以取历史配送时间最长的单品时间作为目标配送时长等。
130.当然，在业务订单内某个单品没有历史配送时间时，可以使用所有时间的历史订单，若所有历史时间无订单，使用该门店所有商品的平均配送时间，若门店没有历史配送时间，则不添加标签，本示例对此种情况不做考虑。
131.在根据业务订单对应的历史配送时长确定出业务订单的目标配送时长之后，执行子步骤n2。
132.子步骤n2：根据所述目标配送时长，对所述业务订单进行评分处理，得到所述业务订单的评分值。
133.在获取到业务订单的目标配送时长之后，可以根据目标配送时长对业务订单进行评分处理，以得到业务订单的评分值，在实际应用中，可以预先针对不同的配送时长段设置对应的评分值，配送时长越长评分值越小，反之，配送时长越短则评分值越大。
134.当然，在具体实现中，一个业务订单可以对应于一种评分维度，也可以对应于多种评分维度，具体地，可以根据业务需求而定，本实施例对此不加以限制。
135.在本实施例中，还可以通过预设页面展示业务订单和评分维度的订单评分，可以给用户以直观感受，具体地，可以结合下述具体实现方式进行详细描述。
136.在本公开的另一种具体实现方式中，在上述步骤203之后，还可以包括：
137.步骤h1：在接收到所述用户对所述业务订单的显示操作之后，根据预设评分策略，对所述业务订单的评分值进行二次评分处理，得到所述业务订单对应的订单评分值。
138.在本实施例中，预设评分策略是指在订单显示页面显示业务订单和订单评分值进行二次评分的策略。
139.在接收到用户对业务订单的显示操作之后，可以根据预设评分策略对业务订单的评分值进行二次评分处理，以得到业务订单对应的订单评分值。
140.在对业务订单的评分值进行二次评分处理得到业务订单对应的订单评分值之后，
执行步骤h2。
141.步骤h2：显示订单显示页面，并将所述业务订单和所述订单评分值显示于所述订单显示页面。
142.在得到业务订单对应的订单评分值之后，可以显示订单显示页面，并将业务订单和订单评分值显示于订单显示页面。
143.在具体实现中，订单显示页面可以为雷达图显示页面，雷达图的是对比当前用户选择的订单，给出的评分并不是各个维度真实的评分，会根据真实评分通过一定方式转换成雷达图评分，强调对比结果的差异，雷达图可自定义评分进制，比如5分制，10分制，不同维度的评分进制有可能与雷达图，当多个订单评分不一致时会通过一定的自研算法做转换，评分转换策略可以为：雷达图评分
‑
＝单个维度评分/单个维度分数制
×
雷达图分数制，例如，配送评分是8.5分，配送评分制是10分制，雷达图分数制是5分制，则转换成雷达图分数为：(8.5/10)*5＝4.25分等。
144.使用雷达图显示业务订单和订单评分的效果可以如图3和图4所示，在雷达图上可以显示业务订单在每个评分维度下的评分，综合分析业务订单的利弊，从整体上给用户参考，帮助用户做出选择。
145.在根据评分维度对业务订单进行评分处理，得到业务订单的评分值之后，执行步骤204。
146.步骤204：获取所述业务订单中评分维度相同的初始业务订单。
147.初始业务订单是指从业务订单中筛选的评分维度相同的业务订单。
148.在得到业务订单的评分值之后，可以获取业务订单中评分维度相同的初始业务订单，例如，业务订单包括订单1、订单2、订单3和订单4，其中，订单1和订单2采用评分维度a进行的评分，订单3和订单4是采用评分维度b进行的评分，此时，可以将订单1和订单2作为评分维度a下的初始业务订单，并将订单3和订单4作为评分维度b下的初始业务订单等。
149.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
150.在获取业务订单中评分维度相同的初始业务订单之后，执行步骤205。
151.步骤205：从所述初始业务订单中筛选出评分值最大的业务订单，并将所述评分值最大的业务订单作为所述目标业务订单。
152.在获取业务订单中的初始业务订单之后，可以从初始业务订单中筛选出评分值最大的业务订单，并将评分值最大的业务订单作为目标业务订单，例如，评分维度a下的初始业务订单包括：订单1、订单2和订单3，其中，订单1、订单2和订单3在评分维度a下的评分值分别为：5、8和10，此时，可以将订单3作为目标业务订单等。
153.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
154.在从初始业务订单中筛选出评分值最大的业务订单，并将评分值最大的业务订单作为目标业务订单之后，执行步骤206。
155.步骤206：为所述目标业务订单添加与所述评分维度关联的订单标签。
156.在确定出业务订单中的目标业务订单之后，可以为目标业务订单添加与评分维度关联的订单标签，例如，在根据配送时长维度确定的目标业务订单为订单1时，则为订单1添
加配送速度较快的订单标签。在根据配送时长维度和门店评分维度确定的目标业务订单均为订单2时，则为订单2添加配送速度较快的订单标签和评分较高的订单标签等。
157.可以理解地，上述示例仅是为了更好地理解本公开的实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
158.本公开的实施例通过综合对比用户选择的多个订单，计算出每个订单的优势，通过打标签的方式可以向用户直观展示订单信息，能够辅助用户快速做出订单选择。
159.本公开的实施例提供的订单标签添加方法，通过获取用户已选择的业务订单，根据业务订单的订单类型，确定业务订单对应的评分维度，根据评分维度对业务订单进行评分处理，得到业务订单的评分值；根据评分值，确定业务订单中的目标业务订单，为目标业务订单添加与评分维度关联的订单标签。本公开的实施例通过综合对比用户选择的多个订单，计算出每个订单的优势，通过打标签的方式可以向用户直观展示订单信息，能够辅助用户快速做出订单选择，提高了用户体验，且提升了订单平台的成单率和留存率。
160.实施例三
161.参照图5，示出了本公开的实施例提供的一种订单标签添加装置的结构示意图，如图5所示，该订单标签添加装置300具体可以包括如下模块：
162.业务订单获取模块310，用于获取用户已选择的业务订单；
163.评分维度确定模块320，用于根据所述业务订单的订单类型，确定所述业务订单对应的评分维度；
164.订单评分获取模块330，用于根据所述评分维度，对所述业务订单进行评分处理，得到所述业务订单的评分值；
165.目标订单确定模块340，用于根据所述评分值，确定所述业务订单中的目标业务订单；
166.订单标签添加模块350，用于为所述目标业务订单添加与所述评分维度关联的订单标签。
167.可选地，所述订单评分获取模块330包括：
168.配送时长确定单元，用于在所述评分维度为配送时长维度的情况下，根据所述业务订单对应的历史配送时长，确定所述业务订单的目标配送时长；
169.订单评分获取单元，用于根据所述目标配送时长，对所述业务订单进行评分处理，得到所述业务订单的评分值。
170.可选地，所述配送时长确定单元包括：
171.第一配送时长获取子单元，用于根据所述业务订单中每个业务对象配送至所述用户对应的配送地址的第一历史配送时长，计算得到所述第一历史配送时长的第一平均值，并将该第一平均值作为所述目标配送时长；
172.第二配送时长获取子单元，用于获取所述业务订单中每个业务对象在距离当前时间为预设时长内的第二历史配送时长，计算得到所述第二历史配送时长的第二平均值，并将该第二平均值作为所述目标配送时长；
173.第三配送时长获取子单元，用于根据所述业务订单中每个业务对象配送至所述用户对应的配送地址的第三历史配送时长，获取所述第三历史配送时长中的最大值，并将该最大值作为所述目标配送时长。
174.可选地，所述装置还包括：
175.订单评分值获取模块，用于在接收到所述用户对所述业务订单的显示操作之后，根据预设评分策略，对所述业务订单的评分值进行二次评分处理，得到所述业务订单对应的订单评分值；
176.订单评分显示模块，用于显示订单显示页面，并将所述业务订单和所述订单评分值显示于所述订单显示页面。
177.本公开的实施例提供的订单标签添加装置，通过获取用户已选择的业务订单，根据业务订单的订单类型，确定业务订单对应的评分维度，根据评分维度对业务订单进行评分处理，得到业务订单的评分值；根据评分值，确定业务订单中的目标业务订单，为目标业务订单添加与评分维度关联的订单标签。本公开的实施例通过综合对比用户选择的多个订单，计算出每个订单的优势，通过打标签的方式可以向用户直观展示订单信息，能够辅助用户快速做出订单选择，提高了用户体验，且提升了订单平台的成单率和留存率。
178.实施例四
179.参照图6，示出了本公开的实施例提供的另一种订单标签添加装置的结构示意图，如图6所示，该订单标签添加装置400具体可以包括如下模块：
180.业务订单获取模块410，用于获取用户已选择的业务订单；
181.评分维度确定模块420，用于根据所述业务订单的订单类型，确定所述业务订单对应的评分维度；
182.订单评分获取模块430，用于根据所述评分维度，对所述业务订单进行评分处理，得到所述业务订单的评分值；
183.目标订单确定模块440，用于根据所述评分值，确定所述业务订单中的目标业务订单；
184.订单标签添加模块450，用于为所述目标业务订单添加与所述评分维度关联的订单标签。
185.可选地，所述目标订单确定模块440包括：
186.初始业务订单获取单元441，用于获取所述业务订单中评分维度相同的初始业务订单；
187.目标业务订单获取单元442，用于从所述初始业务订单中筛选出评分值最大的业务订单，并将所述评分值最大的业务订单作为所述目标业务订单。
188.本公开的实施例提供的订单标签添加装置，通过获取用户已选择的业务订单，根据业务订单的订单类型，确定业务订单对应的评分维度，根据评分维度对业务订单进行评分处理，得到业务订单的评分值；根据评分值，确定业务订单中的目标业务订单，为目标业务订单添加与评分维度关联的订单标签。本公开的实施例通过综合对比用户选择的多个订单，计算出每个订单的优势，通过打标签的方式可以向用户直观展示订单信息，能够辅助用户快速做出订单选择，提高了用户体验，且提升了订单平台的成单率和留存率。
189.本公开的实施例还提供了一种电子设备，包括：处理器、存储器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述程序时实现前述实施例的订单标签添加方法。
190.本公开的实施例还提供了一种可读存储介质，当所述存储介质中的指令由电子设
备的处理器执行时，使得电子设备能够执行前述实施例的订单标签添加方法。
191.对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
192.在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本公开的实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本公开的实施例的内容，并且上面对特定语言所做的描述是为了披露本公开的实施例的最佳实施方式。
193.在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本公开的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
194.类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本公开的示例性实施例的描述中，本公开的实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本公开的实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本公开的实施例的单独实施例。
195.本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的替代特征来代替。
196.本公开的实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本公开的实施例的动态图片的生成设备中的一些或者全部部件的一些或者全部功能。本公开的实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序。这样的实现本公开的实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
197.应该注意的是上述实施例对本公开的实施例进行说明而不是对本公开的实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本公开的实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干
个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
198.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
199.以上所述仅为本公开的实施例的较佳实施例而已，并不用以限制本公开的实施例，凡在本公开的实施例的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本公开的实施例的保护范围之内。
200.以上所述，仅为本公开的实施例的具体实施方式，但本公开的实施例的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开的实施例揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的实施例的保护范围之内。因此，本公开的实施例的保护范围应以权利要求的保护范围为准。