CN113610589A

CN113610589A - 订单确认信息处理方法及装置

Info

Publication number: CN113610589A
Application number: CN202110769689.4A
Authority: CN
Inventors: 沈皎琦; 徐梦霖
Original assignee: Alibaba China Co Ltd
Current assignee: Alibaba China Co Ltd
Priority date: 2021-07-07
Filing date: 2021-07-07
Publication date: 2021-11-05

Abstract

本申请实施例公开了订单确认信息处理方法、装置及电子设备，所述方法包括：确定待确认订单关联的目标商品对象，以及所述目标商品对象关联的多项待确认信息；确定所述多项待确认信息分别所属的多个主类别；按照待确认信息之间的属性相关性，将同一主类别下的多项待确认信息划分为多个子类别；从所述子类别的划分结果中，确定所述多个主类别中分别待展示的关键信息；在用于展示订单确认信息的目标页面中对所述关键信息进行优先展示。通过本申请实施例，能够提升用户获取信息的效率，进而帮助提升页面转化率。

Description

订单确认信息处理方法及装置

技术领域

本申请涉及信息处理技术领域，特别是涉及订单确认信息处理方法及装置。

背景技术

在商品对象信息系统的交易下单链路中，用户可以通过搜索等方式查找到符合需求的商品对象，通过点击“立即购买”或者加入“购物车”之后再点击“结算”等方式，可以进入到“确认订单”页面。在该页面中可以对多项信息进行确认，确认无误之后可以提交订单并执行付款等操作。

其中，随着越来越多的信息表达和定制建设，“确认订单”页面中展示出的信息通常会非常多，例如，具体包括对收货地址、商品SKU(库存量单位)、数量、配送方式、配送时间、是否购买或者享用商家赠送的运费险、店铺优惠信息、是否开具发票、支付方式等各项信息的确认。通过这种方式，可以通过同一页面完成对多项信息的确认。但是，过多信息的表达导致页面很长，用户在下单环节接收信息较多，交易决策成本增大。

发明内容

本申请提供了订单确认信息处理方法及装置，能够提升用户获取信息的效率，进而帮助提升页面转化率。

本申请提供了如下方案：

一种订单确认信息处理方法，包括：

确定待确认订单关联的目标商品对象，以及所述目标商品对象关联的多项待确认信息；

确定所述多项待确认信息分别所属的多个主类别；

按照待确认信息之间的属性相关性，将同一主类别下的多项待确认信息划分为多个子类别；

从所述子类别的划分结果中，确定所述多个主类别中分别待展示的关键信息；

在用于展示订单确认信息的目标页面中对所述关键信息进行优先展示。

其中，所述主类别包括服务信息类；

所述将同一主类别下的多项待确认信息划分为多个子类别，包括：

将所述服务信息类下的多项待确认信息划分为以下子类别中的部分或全部：配送服务类、退换货利益点类、增值服务类、保障服务类、发票服务类。

其中，所述根据所述子类别的划分结果，确定所述多个主类别中分别待展示的关键信息，包括：

从所述多个子类别中选择目标数目的关键子类别，和/或，从同一子类别中选择关键的待确认信息内容。

其中，所述在用于展示订单确认信息的目标页面中对所述关键信息进行优先展示，包括：

在所述目标页面中所述服务信息类对应的区域提供多个宫格化子区域，并在所述多个宫格化子区域内对多个关键子类别中的关键待确认信息进行显性的聚合展示，对非关键子类别以及非关键的待确认信息进行隐藏。

其中，所述在所述多个宫格化子区域内对多个关键子类别中的关键待确认信息进行显性的聚合展示，包括：

在同一宫格化子区域内，以主标题加副标题的形式，对同一关键子类别中的关键待确认信息进行显性的聚合展示，其中，主标题对应的关键待确认信息的重要程度高于所述副标题对应的关键待确认信息。

其中，还包括：

在所述服务信息类对应的区域中提供用于展开展示的操作选项；

在通过该操作选项接收到展开操作请求后，在所述服务信息类对应的区域中创建扩展的宫格化子区域，以便通过所述扩展的宫格化子区域将隐藏的子类别的信息进行展开展示。

其中，还包括：

接收到对所述宫格化子区域执行的目标操作后，通过浮层的方式对对应关键子类别下的待确认信息的详情进行展开展示，并提供用于进行修改操作的操作选项；

通过所述操作选项接收到修改操作后，将所述宫格化子区域中展示的关键待确认信息进行同步修改。

其中，将所述关键信息中有利于帮助用户进行决策且处于已选中状态的信息进行增强展示。

根据所述子类别的划分结果，以及用户所属的用户群体特征，确定所述服务信息类中待展示的关键信息。

其中，所述主类别包括金额信息类；

将所述金额信息类下的多项待确认信息划分为：合计金额类，优惠金额类；

所述根据所述子类别的划分结果，确定所述多个主类别中待展示的关键信息，包括：

分别根据合计金额类、优惠金额类下的一项或多项金额信息，计算出总合计金额以及总优惠金额，并根据所述总合计金额、总优惠金额计算出应付金额，将所述总合计金额、总优惠金额以及所述应付金额确定为所述金额信息类中待展示的关键信息。

以计算公式的形式，提供所述总合计金额、总优惠金额以及应付金额信息。

其中，还包括：

提供用于对所述总合计金额或总优惠金额进行展开展示的操作选项；

通过该操作选项接收到用户请求后，将所述合计金额类或优惠金额类下的多项金额信息的明细进行展开展示。

其中，还包括：

如果在同一屏内未能将全部关键信息进行展示，则在所述目标页面中提供关于尚未展示的关键信息的提示信息。

其中，所述目标页面包括：

通用的订单确认信息展示页面；

或者，

用于对同一商家用户的多个被指定为待购买状态的商品对象进行展示的页面，在其中一个或多个商品对象被选中为所述目标商品对象后，在该页面中展示订单确认信息。

一种订单确认方法，包括：

提供订单确认界面，所述订单确认界面用于对目标商品对象关联的多个主类别下关键的待确认信息进行展示，其中所述主类别下包括多个子类别，所述关键的待确认信息包括多个关键子类别下分别对应的关键待确认信息；

根据接收到的确认结果完成订单确认。

一种订单确认信息处理装置，包括：

待确认信息确定单元，用于确定待确认订单关联的目标商品对象，以及所述目标商品对象关联的多项待确认信息；

主类别确定单元，用于确定所述多项待确认信息分别所属的多个主类别；

子类别划分单元，用于按照待确认信息之间的属性相关性，将同一主类别下的多项待确认信息划分为多个子类别；

关键信息确定单元，用于从所述子类别的划分结果中，确定所述多个主类别中分别待展示的关键信息；

关键信息优先展示单元，用于在用于展示订单确认信息的目标页面中对所述关键信息进行优先展示。

一种订单确认装置，包括：

界面提供单元，用于提供订单确认界面，所述订单确认界面用于对目标商品对象关联的多个主类别下关键的待确认信息进行展示，其中所述主类别下包括多个子类别，所述关键的待确认信息包括多个关键子类别下分别对应的关键待确认信息；

确认完成单元，用于根据接收到的确认结果完成订单确认。

一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述任一项所述的方法的步骤。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述任一项所述的方法的步骤。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，对于需要进行订单确认的目标商品对象，在确定出多项待确认信息之后，可以进行信息重组、层级处理，将主类别下的多项待确认信息划分为多个子类别，并根据划分结果，确定出具体主类别下的关键信息，之后，可以在页面中对这种关键信息进行优先展示，其他的非关键信息可以暂时进行隐藏等处理，因此，可以有利于缩减页面长度，增强用户对关键信息的感知，提升用户获取信息的效率，进而帮助提升页面转化率。

其中，关于具体商品服务类的主类别，还可以通过宫格化的方式对各子类别中的关键信息进行聚合展示，对于更有利于帮助用户进行决策的关键信息，还可以通过大号加粗字体等方式进行增强展示，通过这种方式可以提升用户对服务信息的感知。

对于金额信息类的主类别，可以收敛出合计金额类以及优惠金额类，并将总合计金额、总优惠金额以及应付金额作为优先展示的关键信息，以此可以提升用户对金额信息的确定性，降低由于计算复杂等方式给用户带来的不便。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的系统架构的示意图；

图2是本申请实施例提供的第一方法的流程图；

图3至图8是本申请实施例提供的界面的示意图；

图9是本申请实施例提供的第二方法的流程图；

图10是本申请实施例提供的第一装置的示意图；

图11是本申请实施例提供的第二装置的示意图；

图12是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

首先需要说明的是，本申请发明人在实现本申请的过程中发现，现有技术中的订单确认页面中，各项具体的待确认信息通常以列表的形式进行一一展示。例如，从上至下分别包括收货地址、商品信息、配送方式、配送时间、运费险、店铺优惠、开具发票、商品金额、运费险金额、运费、优惠券、总计金额等等。过多信息的表达使得页面很长，并且，各项待确认信息混在一起，无主次之分，因此，造成信息噪点太多，以至于用户对具体的服务、金额等信息的感知比较低；另外，也存在信息不确定性强、计算复杂等问题，例如，用户可能不知道商品具体的到手价到底是多少，到底可享受哪些服务，等等。

在本申请实施例中，为了在通过订单确认页面呈现多项待确认信息的同时，帮助用户提升决策效率，提供了解决方案。在该解决方案中，对于待确认订单关联的目标商品对象，通过信息重组、层级优化，可以将待确认信息拆解成多个主类别，例如，具体可以包括地址、商品服务、金额、支付方式等四个主类别。在可选的实施方式中，还可以在用于对订单确认信息进行展示的页面中提供多个卡片式展示区域，每个展示区域对应展示一个主类别下的待确认信息。

此外，还可以按照待确认信息之间的属性相关性，将同一主类别下的多项待确认信息划分为多个子类别。例如，对于商品服务这一主类别下的多项待确认信息，可以划分为配送服务类(该子类别下具体可以包括配送费用、配送时间等多项待确认信息)、退换货利益点类(该子类别下具体可以包括商家是否赠送退货险、退换货可赔付金额等多项待确认信息)、增值服务类、保障服务类(该子类别下具体可以包括是否提供赠品、售后服务相关的服务等多项待确认信息)、发票服务类(该子类别下可以包括与开具电子发票相关的待确认信息)等多个子类别。

对于金额类别下的多项待确认信息，可以划分为合计金额类(例如，可以包括商品对象原价信息，购买运费险等所需支付的费用等)、优惠金额类(具体可以包括商家用户提供的优惠金额，系统中的用户积分可兑换的金额等)等多个子类别，等等。

当然，在具体实现时，每个主类别下还可以包括多个层级的子类别，具体可以根据实际场景的需求而定。

在完成子类别的划分之后，可以根据子类别的划分结果，确定出具体主类别中待展示的关键信息。例如，对于商品服务类这一主类别，可以从划分出的多个子类别中选择其中部分子类别作为关键的子类别进行优先展示(例如，可以仅将配送服务类、退换货利益点类、增值服务类等更有利于帮助用户进行决策的信息作为关键的子类别)，另外，还可以从关键的子类别中选择出关键的待确认信息。对于金额类这一主类别，可以根据收敛出的合计金额类、优惠金额类等多个子类别，分别计算出总合计金额，总优惠金额，另外还可以计算出应付金额，将这种总合计金额，总优惠金额以及应付金额确定为关键信息，等等。

最后，可以在用于展示订单确认信息的目标页面中对上述关键信息进行优先展示。由于将主类别下的多项待确认信息进行了收敛，并进行了关键信息提取，因此，有利于简化页面信息，缩短页面长度，同时，展示出的待确认信息具有清晰的主次关系，将更有利于帮助用户进行决策的信息进行优先或者增强展示，以此降低用户的决策成本。

另外，在信息展示形式上，还可以进行进一步的改进。例如，对于商品服务类这一主类别，可以在对应的展示区域内提供多个宫格化子区域，可以在具体的宫格化子区域内分别对多个关键子类别下的关键待确认信息进行显性的聚合展示，非关键信息则可以进行隐藏。也就是说，不再以列表的方式展示出多项具体的待确认信息明细，而是通过这种宫格化的展示方式，使得更重要的信息更突出，加强用户对比较优质服务的感知，进而有利于提升转化率。在宫格化子区域内还可以通过主标题+副标题的形式，进一步突出更为关键的待确认信息，等等。对于资金类这一主类别，可以以公式化的形式，对总合计金额、总优惠金额以及应付金额进行展示，例如，“总合计金额-总优惠金额＝应付金额”，而不必直接展示出各项具体的资金信息明细。这样，可以使得用户可以很直观的获知商品对象的原价是多少，以及总共优惠多少，最终需要支付多少，而不再需要自行进行计算，增强了信息的确定性，并且可以强化用户对具体资金信息的感知，同样有利于帮助用户进行购物决策。

具体从系统架构角度而言，参见图1，本申请实施例可以涉及商品对象信息服务系统的客户端以及服务端，客户端主要用于与用户进行交互，包括对具体页面的展示，对用户操作的接收等。服务端则可以用于进行具体的数据保存、数据处理等，其中包括对具体待确认信息的分类、同一主类别下多项待确认信息的进一步收敛等处理。

下面对本申请实施例提供的具体技术方案进行详细介绍。

实施例一

首先，本申请实施例一提供了一种订单确认信息处理方法，参见图2，该方法可以包括：

S201：确定待进行订单确认的目标商品对象，以及所述目标商品对象关联的多项待确认信息。

具体实现时，可以有多种进入订单确认流程的链路，例如，在用户选择对某商品对象进行“立即购买”后，可以进入到订单确认流程，此时，该商品对象就可以确定为待进行订单确认的目标商品对象。或者，用户选择将一个或多个商品对象加入“购物车”，之后在“购物车”页面中进行商品对象勾选，并点击“去结算”等操作选项，也可以触发订单确认流程，此时，被勾选的一个或多个商品对象就可以是待进行订单确认的目标商品对象。另外，在一些系统中，还可以为用户提供“商家购物车”功能，也即，可以将同一商家的多个商品对象加入到专用于该商家的“购物车”中，也即，“商家购物车”中保存的是用户在同一商家的店铺中选中的一个或多个商品对象。在这种“商家购物车”场景中，还可以为用户提供快速下单功能，例如，在“商家购物车”页面中勾选一个或多个商品对象之后，不需要通过“去结算”等触发进入订单确认页面，而是可以直接在“商家购物车”页面中展示待确认信息。此时，对于用户从“商家购物车”页面中勾选的一个或多个商品对象也可以成为本申请实施例中的目标商品对象，等等。

其中，在确定出目标商品对象之后，还可以确定出该目标商品对象关联的待确认信息，其中可以包括收货地址信息，商品对象的SKU、数量、配送方式、配送时间、运费险等等。在现有技术中，通常是将上述各项信息以列表等形式进行罗列，并在订单确认页面中进行展示。而在本申请实施例中，则首先需要对上述各项待确认信息进行处理，包括信息重组、层级优化等。

S202：确定所述多项待确认信息分别所属的多个主类别。

在确定出多项待确认信息后，首先可以确定出多项待确认信息分别所属的多个主类别。其中，具体的主类别主要可以包括地址、商品服务、金额、支付方式等。具体的，可以直接根据各项待确认信息的属性信息，确定其所属的主类别。例如，地址类别下主要是收货地址相关的信息，包括收货地址、联系方式信息等；商品服务类别下主要包括商品对象自身的待确认信息(包括SKU、数量等)，以及用户可享受的服务相关的待确认信息，包括配送方式、配送时间、运费、运费险、碎屏险，等等；金额类别下主要包括商品对象的原价，如果选择使用某项服务则涉及到的相关费用，商家或者系统提供的优惠信息，等等。支付方式类别下主要包括各种可选的支付方式、支付途径等。

S203：按照待确认信息之间的属性相关性，将同一主类别下的多项待确认信息划分为多个子类别。

在确定出多个主类别之后，本申请实施例中还可以按照待确认信息之间的属性相关性，将同一主类别下的多项待确认信息划分为多个子类别。具体实现时，可以针对包含的待确认信息项目比较多的主类别进行具体的子类别划分处理。例如，在商品服务这一主类别下，可以将配送方式、配送时间、运费等收敛为配送服务类；将运费险、碎屏险等收敛为保险类或者退换货利益点类，增值服务类等；将洗护保养等售后服务相关的待确认信息收敛为保障服务类；将与开具电子发票相关的待确认信息收敛为发票服务类，等等。具体实现时，根据具体目标商品对象的不同，具体可以将商品服务这一主类别下收敛出上述各项子类别中的部分或全部。

另一类涉及到的待确认项目比较多的主类别是金额信息类。例如，包括商品对象原价，优惠价格，如果用户选择使用某些需要付费的服务，则还涉及到这些服务对应的价格，例如，如果用户需要购买运费险，在商家未赠送运费险的情况下，则还需要在结算时支付购买运费险所需的费用，等等。因此，在本申请实施例中，也可以针对资金类别下的多项待确认信息进行重组，收敛出多个子类别。具体的，资金类别下具体可以包括合计金额类以及优惠金额类等多个子类别。例如，商品对象本申请的原价，以及需要为具体的服务所需支付的费用等，可以收敛为合计金额类。关于店铺或者商家为用户提供的优惠信息，系统提供的用户积分可抵扣的金额等，可以收敛为优惠金额类，等等。

S204：根据所述子类别的划分结果，确定所述多个主类别中待展示的关键信息。

完成子类别的收敛后，可以根据具体的收敛结果，确定出具体主类别下待展示的关键信息。其中，对于商品服务类这一主类别，可以从所述多个子类别中选择目标数目的关键子类别，和/或，从同一子类别中选择关键的待确认信息内容。例如，假设收敛出五个子类别，则可以从中选择出三个作为关键的子类别。具体如，可以将配送服务类、退换货利益点类、增值服务类、保障服务类确定为关键的子类别，而关于发票服务类，则可以作为非关键的子类别。或者，还可以从子类别下选择出关键的待确认信息内容。在从具体子类别下选择关键的待确认信息时，可以对更有利于帮助用户进行决策，或者更有利于提升转化率的待确认信息进行选择。例如，对于配送方式类这一子类别，如果商家用户提供“包邮”服务，或者承诺在某日之前送达等，则对于用户而言属于优质的服务；或者，如果商家赠送了运费险服务，使得用户不需要另行购买运费险，即可在后续发生退换货时，获得相应的赔付金额，等等。如果用户感知到此类服务的存在，则有利于形成浏览-购买转化，因此，可以将“包邮”、“预计某日送达”、“赠运费险”等信息作为关键信息。

这里需要说明的是，在实际应用中，具体在确定所述关键信息时，还可以参考具体用户的个性化信息，例如，根据用户所属的用户群体的不同，针对同一商品对象，可以选择不同的子类别作为关键子类别，或者，从同一子类别中选择出不同的待确认信息作为关键信息，等等。例如，对于上班族的用户而言，可能更需要关注发票类的服务，则可以将发票类作为关键子类别；而对于学生或者全职妈妈等用户，则可能不太关注发票类的服务，而更多的时关注增值服务、保障服务等，因此，发票类服务则可以作为非关键的子类别，等等。

另外，关于资金类这一主类别，由于可以收敛为合计金额类以及优惠金额类，因此，可以分别根据合计金额类、优惠金额类下的一项或多项金额信息，计算出总合计金额以及总优惠金额，并根据所述总合计金额、总优惠金额计算出应付金额，将所述总合计金额、总优惠金额以及所述应付金额确定为所述金额信息类中待展示的关键信息。

S205：在用于展示订单确认信息的目标页面中对所述关键信息进行优先展示。

在确定出具体主类别下的关键信息后，可以在目标页面中对所述关键信息进行优先展示。所谓的优先展示具体可以是，在默认状态下仅对属于关键信息的信息进行展示，而对于具体主类别下的非关键子类别，或者非关键的待确认信息则可以进行隐藏。这样可以缩短页面长度，并且使得关键信息更为突出，更有利于增强用户对关键信息的感知，有利于帮助其进行购物决策。

其中，具体在展示方式上，本申请实施例也提供了相应的方案。例如，对于服务信息类这一主类别，可以在所述目标页面中所述服务信息类对应的区域提供多个宫格化子区域，并在所述宫格化子区域内对所述关键信息进行显性展示，非关键信息进行隐藏。也就是说，可以将服务信息划分为多个子类别，并从中选择出关键信息后，进行宫格化展示。例如，如图3所示，其中的31为服务信息类这一主类别对应的展示区域，32处所示为宫格化子区域，每个宫格化子区域中可以对一个关键子类别下的关键待确认信息进行聚合展示。其中，具体在宫格中对关键信息进行展示时，可以以主标题+副标题的形式进行展示，其中，主标题对应的关键待确认信息的重要程度高于所述副标题对应的关键待确认信息。例如，在配送服务类这一子类别中，可以以配送方式作为主标题，配送时间作为副标题，等等。其中，主标题的字体大小可以大于副标题，因此对应展示的信息更容易引起用户的注意。

其中，各子类别之间还可以具有不同的优先级，例如，配送类>保险类/退换货利益点类>增值服务类>其他，等等。具体在宫格化子区域中进行展示时，可以按照上述优先级对各子类别进行排序，当某一优先级对应子类目中的关键信息为空(例如，某商品对象的商家可能没有为用户赠送给运费险，等等)时，则优先级靠后的子类目可以前移。

另外，还可以将有利于帮助用户进行决策的信息，或者较为优质的服务信息等，进行增强展示。例如，对于“包邮”、“赠运费险”等比较优质的服务，可以用大号、加粗字体进行增强展示，而关于配送时间等则可以采用常规字体信息展示，等等。这种宫格化展示的信息相比于列表展示而言，可以具有更直观等特点，更有利于强化用户对服务信息的感知。

再者，还可以在所述服务信息类对应的区域中提供用于展开展示的操作选项，在通过该操作选项接收到展开操作请求后，可以在所述服务信息类对应的区域中创建扩展的宫格化子区域，以便通过所述扩展的宫格化子区域将隐藏的子类别的信息进行展开展示。例如，假设某商品对象共收敛出五个子类别，如图4(A)所示，将其中三个子类别作为关键信息在目标页面中进行了显性展示，具体的关键信息包括运费信息、运费险信息、保障服务信息等。此时，还可以提供用于执行展开操作的操作选项，如41处所示，在点击该操作选项后，可以展开如图4(B)所示，可以将隐藏的发票相关的服务信息、备注信息等进行展示。

由于通常还可以由用户对是否享受具体的服务进行选择，例如，对于商家赠送的运费险，可以由用户自行选择是否使用，等等。因此，还可以将具体的宫格化子区域置为可操作状态，接收到对具体的宫格执行的目标操作后，可以提供用于对具体的待确认信息执行状态修改操作的操作选项，包括将“赠运费险”服务从未选中状态修改为选中状态，或者，将发票服务从“不开发票”修改为“开发票”，并确定具体的发票信息等。为了便于实现，可以在上述宫格化子区域的基础上实现轻交互，具体的，可以在接收到对某宫格的点击等操作后，通过浮层的方式对对应子类别下的待确认信息的详情进行展开展示，并提供用于进行修改操作的操作选项，通过所述操作选项接收到修改操作后，可以将宫格中展示的关键信息进行同步修改。例如，在默认状态下，用户未使用商家提供的“赠运费险”服务，此时，在对应的宫格处可以用普通字体显示“赠运费险”等字样，也即，提示用户该项服务可用。在用户将“赠运费险”服务从未选中状态修改为选中状态之后，可以将宫格处的“赠运费险”字样修改为大号加粗字体展示，等等。

需要说明的是，一些商品对象可能会采用预售模式进行销售，用户在下单时可以首先支付定金，然后在指定的时间段内支付剩余的尾款。对于这种情况，在本申请实施例中，还可以在商品及服务区块中，提供关于定金以及尾款信息。具体的，可以在商品及服务区块中提供定金及尾款信息分别对应的宫格化子区域，在支付定金阶段，如图5(A)所示，可以将待支付的定金金额进行突出展示，另外还可以在尾款信息所在的宫格中，对支付尾款的金额、时间、用户权益使用方式等信息进行展示。在支付尾款阶段，如图5(B)所示，可以在尾款所在的宫格中，对待支付的尾款金额进行突出展示，其中，如果有可用的优惠券等，则可以在该宫格中对商品总价减去定金金额以及各类优惠金额等之后的金额进行展示。

对于金额信息类这一主类别，由于主要可以收敛为合计金额类以及优惠金额类等子类别，并且可以将总合计金额、总优惠金额以及应付金额信息确定为关键信息，因此，为了便于用户更直观地感知到金额相关的信息，包括原本的总合计是多少金额，总共优惠了多少金额，最终实际需要支付多少金额，因此，可以以计算公式的形式，提供所述总合计金额、总优惠金额以及应付金额信息。例如，如图3中的33处所示，具体可以“总合计金额-总优惠金额＝应付金额”的计算公式形式，展示出上述各项关键信息。以此增强用户对金额信息的感知，提升用户对金额信息的确定性，减少计算过程给用户带来的不便。

当然，具体实现时，还可以提供用于对所述总合计金额或总优惠金额进行展开展示的操作选项，例如，具体可以在“总合计金额”或者“总优惠金额”的下方等处提供上述操作选项。通过该操作选项接收到用户请求后，可以将所述合计金额类或优惠金额类下的多项金额信息的明细进行展开展示。例如，总合计金额包括了商品对象本身的价格，购买的运费险的价格，购买的延长质保时间服务的价格，等等，在默认状态下，可以在公式中仅展示出总合计金额，在用户点击总合计金额下方的展开选项之后，再将上述各项具体的价格明细进行展开展示；类似的，假设某商品对象的优惠金额包括了商家提供的优惠券金额，系统提供的满减优惠金额，用户在系统中累计的积分可抵扣的金额，等等，在默认状态下，也可以仅展示总优惠金额，在用户点击总优惠金额下方的展开选项之后，再将各项优惠明细进行展开展示，等等。

总之，由于用户在下单过程中，对于金额信息，通常更想关注的是到底总共能够享受多少优惠，最终实际需要支付的金额是多少，关于各项具体的明细，可能在其次，因此，在本申请实施例中，可以将金额信息相关的多项待确认信息收敛成合计金额与优惠金额两个子类别，并在默认状态下仅提供总各合计金额以及总优惠金额、应付金额等用户更为关心的关键信息。对于各项具体的明细内容，可以仅在用户触发后进行展开展示，以此有利于缩减页面长度，区分待确认信息之间的主次关系，增强用户对金额信息的确定性，降低计算及理解难度，因此，有利于提升用户的信息获取效率。

需要说明的是，关于收货地址、支付方式等类别的待确认信息，由于具体主类别下的待确认信息数量可能并不会太多，因此，具体的收敛处理可以仅在必要情况下进行，一般情况下可以不必进行收敛。但是，无论是否进行收敛，在展示方式方面，都可以采用宫格化的形式进行展示。例如，如图6中的61处所示，对于支付方式信息，也可以将传统的列表式展示方式修改为宫格化的展示方式，以此提升用户对支付方式信息的感知。

由于本申请实施例中将商品服务、金额信息等主类别下的多项待确认信息进行了收敛，并在收敛的基础上对关键信息进行优先展示，其他的非关键信息可以暂时进行隐藏，以此可以缩减页面长度。因此，在多数情况下，同一商品对象的待确认信息可以在同一屏内展示完全。当然，在可能存在在同一屏内无法将各项信息展示完全的情况，例如，一些小屏的终端设备，每一屏内展示的信息量有限，或者，对于在“购物车”页面中勾选了多个商品对象之后发起结算的情况下，由于同一订单确认页面中需要展示多个商品对象的待确认信息，因此，即使按照本申请实施例的方式进行了收敛，也可能无法在同一屏内将各项待确认信息展示完全。对于这种情况，还可以在目标页面中提供关于尚未展示的关键信息的提示信息。例如，假设排在最下方的支付类别的信息未能展示，则如图7(A)中的71处所示，可以提供对应的提示信息，以用于提示用户，可以通过下滑等操作，对支付方式进行选择或者修改等操作。另外，在提供关于支付方式相关的提示信息时，还可以在提示信息中对推荐使用的支付方式进行提示。例如，某商品对象可以支持分期付款、“先用后付”，也可以使用普通的支付方式进行支付，则在对支付方式信息进行提示时，可以对分期付款、“先用后付”等更有利于带来转化的支付方式进行提示，等等。该提示信息还可以置为可操作状态，在用户对该提示信息进行点击操作时，如图7(B)所示，可以将各种支付方式信息进行展示，用户可以对希望使用的支付方式进行勾选操作。

另外需要说明的是，在本申请实施例中，具体用于对订单确认信息进行展示的目标页面可以有多种，例如，可以包括通过在商品对象详情页等页面中点击“立即购买”后跳转进入的通用订单确认页面，或者，在“购物车”页面中勾选一个或多个商品对象并点击“去结算”之后跳转进入的通用订单确认页面。或者，还可以包括“店铺购物车”场景中，“店铺购物车”页面可以用于对同一店铺的多个被指定为待购买状态的商品对象进行展示，例如，如图8(A)所示，用户在某店铺中选择了多个商品对象，并加入该店铺专属的“购物车”中，在其中一个或多个商品对象被勾选为待结算的目标商品对象后，还可以直接在该页面中展示订单确认信息。此时，该“店铺购物车”页面可以为用于展示订单确认信息的目标页面，相应的，如图8(B)所示，在该“店铺购物车”页面中中展示待确认信息时，可以以宫格的形式对商品服务类的关键信息进行展示，以计算公式的方式对金额类的关键信息进行展示，等等。另外，该页面中还可以包括支付方式等待确认信息，用户通过上滑等操作，可以如图8(C)所示，展示出其他的待确认信息。

具体实现时，针对上述“店铺购物车”场景，还可以在商品及服务区块右下方等处展示商品件数，以及合计金额。另外，针对“店铺购物车”商品总价为多个商品对象的情况，还可以点击展示各个商品对象总价。增值费用部分：运费为主订单维度，可以展示出店铺维度的运费信息、税费等的加总结果，点击可以展开各个商品对象的税费明细。运费险也可以为主订单维度，在店铺维度对运费险费用、保价险费用进行加总展示，点击展开各个商品对象的保价险明细。

为了更好的理解本申请实施例提供的技术方案，下面通过一个实际应用中的例子，对订单确认界面的具体展示情况进行介绍。如图3所示，在具体的订单确认界面中，可以包括地址、商品及服务、金额、支付方式等四个大卡片。其中，在地址卡片中，可以展示出收货地址、联系人、联系方式等信息。其中，收货地址在第一行，联系人以及联系方式在第二行；在具体实现时，还可以通过上滑等方式仅在该大卡中展示出单行地址。

在商品对象及服务大卡中，首行可以展示店铺或者门店信息，之后是商品对象信息，包括商品图片、商品标题、SKU信息、单价、数量等信息。商品对象信息之后可以包括多个宫格，每个宫格用于展示服务类别下一个关键子类别中的关键待确认信息，具体配送类关键待确认信息，运费险类的关键待确认信息，发票类的关键待确认信息等。其中，配送类的关键待确认信息中，以配送方式“包邮”为主标题，配送时间“后一天21：00前送达”为副标题。在运费险类的关键待确认信息中，以“赠运费险”为主标题，以“退换货可赔4元”为副标题；在发票类的关键待确认信息中，以“开发票”为主标题，以具体发票类型信息等作为副标题，等等。另外，如果关联有赠品等信息，则可以将赠品信息以缩略图等形式展示在主商品图旁边等方式进行展示。

在金额大卡中，包括总合计金额、共减金额(也即，总优惠金额)、应付金额，以公式的形式展示出三者之间的关系。其中，总合计金额、共减金额下方可以有展开组件，展开后可以查看总合计金额、共减金额的明细。例如，总合计金额展开后可以展示出商品总价+增值服务费用(例如，购买报价险、运费险的费用等)等方式进行展示。其中，增值服务费用可以进行平铺展示，并且，可以仅当增值服务费用大于0时才进行展示，否则可以不进行展示。共减费用可以包括店铺优惠、资产(例如，可跨店铺使用的品类券、满减券、积分等)，等等。

在支付大卡中，可以对各种可选的支付方式进行展示，具体还可以通过宫格化的方式对支付方式信息进行展示，等等。

总之，通过本申请实施例，对于需要进行订单确认的目标商品对象，在确定出多项待确认信息之后，可以进行信息重组、层级处理，将主类别下的多项待确认信息收敛为多个子类别，并根据收敛结果，确定出具体主类别下的关键信息，之后，可以在页面中对这种关键信息进行优先展示，其他的非关键信息可以暂时进行隐藏等处理，因此，可以有利于缩减页面长度，增强用户对关键信息的感知，提升用户获取信息的效率，进而帮助提升页面转化率。

其中，关于具体商品服务类的主类别，还可以通过宫格化的方式对各项关键信息进行展示，对于更有利于帮助用户进行决策的关键信息，还可以通过大号加粗字体等方式进行增强展示，通过这种方式可以提升用户对服务信息的感知。

实施例二

该实施例二提供了一种订单确认方法，参见图9，该方法可以包括：

S901：提供订单确认界面，所述订单确认界面用于对目标商品对象关联的多个主类别下关键的待确认信息进行展示，其中所述主类别下包括多个子类别，所述关键的待确认信息包括多个关键子类别下分别对应的关键待确认信息；

S902：根据接收到的确认结果完成订单确认。

关于该实施例二中的未详述部分，可以参见实施例一中的记载，这里不再赘述。

需要说明的是，本申请实施例中可能会涉及到对用户数据的使用，在实际应用中，可以在符合所在国的适用法律法规要求的情况下(例如，用户明确同意，对用户切实通知，等)，在适用法律法规允许的范围内在本文描述的方案中使用用户特定的个人数据。

与实施例一相对应，本申请实施例还提供了一种订单确认信息处理装置，参见图10，该装置可以包括：

待确认信息确定单元1001，用于确定待确认订单关联的目标商品对象，以及所述目标商品对象关联的多项待确认信息；

主类别确定单元1002，用于确定所述多项待确认信息分别所属的多个主类别；

子类别划分单元1003，用于按照待确认信息之间的属性相关性，将同一主类别下的多项待确认信息划分为多个子类别；

关键信息确定单元1004，用于从所述子类别的划分结果中，确定所述多个主类别中分别待展示的关键信息；

关键信息优先展示单元1005，用于在用于展示订单确认信息的目标页面中对所述关键信息进行优先展示。

其中，所述主类别包括服务信息类；

所述子类别划分单元具体可以用于：

此时，所述关键信息确定单元具体可以用于：

相应的，所述关键信息优先展示单元具体可以用于：

具体的，所述关键信息优先展示单元可以用于：

另外，该装置还可以包括：

第一操作选项提供单元，用于在所述服务信息类对应的区域中提供用于展开展示的操作选项；

第一展开展示单元，用于在通过该操作选项接收到展开操作请求后，在所述服务信息类对应的区域中创建扩展的宫格化子区域，以便通过所述扩展的宫格化子区域将隐藏的子类别的信息进行展开展示。

另外，该装置还可以包括：

第二展开展示单元，用于接收到对所述宫格化子区域执行的目标操作后，通过浮层的方式对对应关键子类别下的待确认信息的详情进行展开展示，并提供用于进行修改操作的操作选项；

待确认信息修改单元，用于通过所述操作选项接收到修改操作后，将所述宫格化子区域中展示的关键待确认信息进行同步修改。

具体实现时，关键信息确定单元具体可以用于：

另外，所述主类别包括金额信息类；

此时，所述子类别划分单元具体可以用于：

所述关键信息确定单元具体可以用于：

另外，所述关键信息优先展示单元具体可以用于：

此时，该装置还可以包括：

第二操作选项提供单元，用于提供用于对所述总合计金额或总优惠金额进行展开展示的操作选项；

第三展开展示单元，用于通过该操作选项接收到用户请求后，将所述合计金额类或优惠金额类下的多项金额信息的明细进行展开展示。

再者，该装置还可以包括：

提示单元，用于如果在同一屏内未能将全部关键信息进行展示，则在所述目标页面中提供关于尚未展示的关键信息的提示信息。

其中，所述目标页面包括：

通用的订单确认信息展示页面；

或者，

与实施例二相对应，本申请实施例还提供了一种订单确认装置，参见图11，该装置可以包括：

界面提供单元1101，用于提供订单确认界面，所述订单确认界面用于对目标商品对象关联的多个主类别下关键的待确认信息进行展示，其中所述主类别下包括多个子类别，所述关键的待确认信息包括多个关键子类别下分别对应的关键待确认信息；

确认完成单元1102，用于根据接收到的确认结果完成订单确认。

另外，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述方法实施例中任一项所述的方法的步骤。

以及一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行前述方法实施例中任一项所述的方法的步骤。

其中，图12示例性的展示出了电子设备的架构，例如，设备1200可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理，飞行器等。

参照图12，设备1200可以包括以下一个或多个组件：处理组件1202，存储器1204，电源组件1206，多媒体组件1208，音频组件1210，输入/输出(I/O)的接口1212，传感器组件1214，以及通信组件1216。

处理组件1202通常控制设备1200的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理元件1202可以包括一个或多个处理器1220来执行指令，以完成本公开技术方案提供的方法的全部或部分步骤。此外，处理组件1202可以包括一个或多个模块，便于处理组件1202和其他组件之间的交互。例如，处理部件1202可以包括多媒体模块，以方便多媒体组件1208和处理组件1202之间的交互。

存储器1204被配置为存储各种类型的数据以支持在设备1200的操作。这些数据的示例包括用于在设备1200上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1204可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1206为设备1200的各种组件提供电力。电源组件1206可以包括电源管理系统，一个或多个电源，及其他与为设备1200生成、管理和分配电力相关联的组件。

多媒体组件1208包括在设备1200和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1208包括一个前置摄像头和/或后置摄像头。当设备1200处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1210被配置为输出和/或输入音频信号。例如，音频组件1210包括一个麦克风(MIC)，当设备1200处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1204或经由通信组件1216发送。在一些实施例中，音频组件1210还包括一个扬声器，用于输出音频信号。

I/O接口1212为处理组件1202和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件1214包括一个或多个传感器，用于为设备1200提供各个方面的状态评估。例如，传感器组件1214可以检测到设备1200的打开/关闭状态，组件的相对定位，例如所述组件为设备1200的显示器和小键盘，传感器组件1214还可以检测设备1200或设备1200一个组件的位置改变，用户与设备1200接触的存在或不存在，设备1200方位或加速/减速和设备1200的温度变化。传感器组件1214可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1214还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1214还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1216被配置为便于设备1200和其他设备之间有线或无线方式的通信。设备1200可以接入基于通信标准的无线网络，如WiFi，或2G、3G、4G/LTE、5G等移动通信网络。在一个示例性实施例中，通信部件1216经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信部件1216还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，设备1200可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1204，上述指令可由设备1200的处理器1220执行以完成本公开技术方案提供的方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的订单确认信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims

1.一种订单确认信息处理方法，其特征在于，包括：

确定所述多项待确认信息分别所属的多个主类别；

2.根据权利要求1所述的方法，其特征在于，

所述主类别包括服务信息类；

3.根据权利要求2所述的方法，其特征在于，

所述根据所述子类别的划分结果，确定所述多个主类别中分别待展示的关键信息，包括：

4.根据权利要求3所述的方法，其特征在于，

所述在用于展示订单确认信息的目标页面中对所述关键信息进行优先展示，包括：

5.根据权利要求4所述的方法，其特征在于，

所述在所述多个宫格化子区域内对多个关键子类别中的关键待确认信息进行显性的聚合展示，包括：

6.根据权利要求4所述的方法，其特征在于，还包括：

7.根据权利要求4所述的方法，其特征在于，还包括：

8.根据权利要求4所述的方法，其特征在于，

将所述关键信息中有利于帮助用户进行决策且处于已选中状态的信息进行增强展示。

9.根据权利要求2所述的方法，其特征在于，

10.根据权利要求1所述的方法，其特征在于，

所述主类别包括金额信息类；

11.根据权利要求10所述的方法，其特征在于，

12.一种订单确认方法，其特征在于，包括：

根据接收到的确认结果完成订单确认。

13.一种订单确认信息处理装置，其特征在于，包括：

14.一种订单确认装置，其特征在于，包括：

确认完成单元，用于根据接收到的确认结果完成订单确认。