CN109934658A - 一种数据处理方法、显示方法及计算设备 - Google Patents

Abstract

一种数据处理方法，包括：接收点餐对象的点餐请求后，确定点餐对象的用餐特征；根据用餐特征，确定提供给点餐对象的推荐菜单。如此，实现菜单推荐，从而缩短用户点菜时间，并提高用户体验。

Description

一种数据处理方法、显示方法及计算设备

技术领域

本申请涉及但不限于数据处理技术领域，尤其涉及一种数据处理方法、显示方法及计算设备。

背景技术

随着终端应用程序(APP，Application)的不断普及，越来越多的商家提供APP点餐或者扫码点餐等电子点餐服务。比如，用户携带手机到餐馆用餐时，可以利用手机内的APP扫描餐馆内餐桌上设置的二维码，即可获取到菜单，然后用户在手机上点选菜品提交后，餐馆可以根据提交的菜单给用户上菜，用户用餐完毕后，结账离开。可见，通过上述点餐方式可以节省实体菜单的成本，并且可以提高点餐效率。

然而，目前的电子点餐服务存在一些不足之处。比如，针对用户而言，较多用户存在选择困难症，难以在大量菜品中快速点菜，特别是面对第一次去的餐馆，更难以快速进行下单；针对餐馆而言，希望用户能够快速点菜以接待更多的顾客，又担心遇到恶意刷差评用户甚至霸王餐用户。

发明内容

以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。

本申请实施例提供一种数据处理方法、显示方法及计算设备，实现菜单推荐，从而缩短用户点菜时间，提高用户体验。

第一方面，本申请实施例提供一种数据处理方法，包括：

接收点餐对象的点餐请求后，确定所述点餐对象的用餐特征；

根据所述用餐特征，确定提供给所述点餐对象的推荐菜单。

在示例性实施方式中，所述用餐特征可以包括以下至少之一：用餐人数、消费价位、口味偏好、营养成分。

在示例性实施方式中，所述确定点餐对象的用餐特征，可以包括以下至少之一：

根据所述点餐请求携带的信息，确定所述点餐对象的用餐特征；

根据所述点餐对象的历史点餐数据，确定所述点餐对象的用餐特征；

根据所述点餐对象的输入信息，确定所述点餐对象的用餐特征。

在示例性实施方式中，所述根据所述用餐特征，确定提供给所述点餐对象的推荐菜单，可以包括以下至少之一：

从供餐对象的历史菜单中筛选出符合所述点餐对象的用餐特征的一个或多个历史菜单，根据筛选出的历史菜单，确定提供给所述点餐对象的推荐菜单；

根据对供餐对象的菜品的点评数据，确定所述供餐对象的推荐菜品；从所述供餐对象的推荐菜品中筛选出符合所述点餐对象的用餐特征的菜品组合，将所述筛选出的菜品组合作为提供给所述点餐对象的推荐菜单。

在示例性实施方式中，所述用餐特征至少可以包括用餐人数；所述根据所述用餐特征，确定提供给所述点餐对象的推荐菜单，可以包括：

根据所述用餐人数以及供餐对象的人均消费费用，计算第一点餐总价；

根据所述点餐对象的用餐人数，确定所述供餐对象提供的与所述用餐人数对应的推荐菜品种类；

按照设定规则选择所述推荐菜品种类中的菜品，并根据选择出的菜品的价格，计算第二点餐总价；

根据所述第一点餐总价和所述第二点餐总价的比较结果，调整所选择的菜品，直至所述第一点餐总价和所述第二点餐总价的差值绝对值满足第一条件；

确定提供给所述点餐对象的推荐菜单为调整后所选择出的菜品组合。

在示例性实施方式中，所述按照设定规则选择所述推荐菜品种类中的菜品，可以包括以下之一：

针对任一种推荐菜品种类，随机选择一种或多种高频菜品，其中，所述高频菜品为历史点选次数大于或等于阈值的菜品；

在任一种推荐菜品种类中选择推荐菜品，其中，所述推荐菜品由所述供餐对象预设，或者，根据菜品点评数据确定；

针对任一种推荐菜品种类，选择其中价格满足第二条件的菜品。

在示例性实施方式中，上述方法还可以包括：

接收点餐对象的点餐请求后，确定所述点餐对象的信誉指数；

若所述点餐对象的信誉指数满足第三条件，则向供餐对象发出提醒消息。

在示例性实施方式中，若所述点餐对象的信誉指数满足第三条件，则根据所述用餐特征，确定提供给所述点餐对象的推荐菜单，可以包括：

根据所述点餐对象的用餐特征和信誉指数，确定提供给所述点餐对象的推荐菜单。

在示例性实施方式中，所述确定所述点餐对象的信誉指数，可以包括：

根据所述点餐对象的历史点餐数据，确定所述点餐对象的信誉指数特征；

根据所述点餐对象的信誉指数特征，确定所述点餐对象的信誉指数。

第二方面，本申请实施例提供一种数据处理方法，包括：

确定用餐特征；

根据供餐对象的历史点餐数据，确定对应于所述用餐特征的至少两个推荐菜单；其中，所述至少两个推荐菜单对应的所述用餐特征的特征值不同。

在示例性实施方式中，所述用餐特征可以包括以下至少之一：用餐人数、消费价位、口味偏好、营养成分。

第三方面，本申请实施例提供一种数据处理方法，包括：

接收点餐对象的点餐请求后，确定所述点餐对象的信誉指数；

若所述点餐对象的信誉指数满足第三条件，则向供餐对象发出提醒消息。

在示例性实施方式中，所述确定所述点餐对象的信誉指数，可以包括：

根据所述点餐对象的历史点餐数据，确定所述点餐对象的信誉指数特征；

根据所述点餐对象的信誉指数特征，确定所述点餐对象的信誉指数。

第四方面，本申请实施例提供一种显示方法，包括：

提供一个显示界面，所述显示界面用于显示一个或多个推荐菜单；

其中，所述推荐菜单包括多种菜品以及所述多种菜品对应的整体价格；所述整体价格根据所述多种菜品的价格计算得到。

在示例性实施方式中，所述显示界面还可以用于提供点餐信息输入界面。

第五方面，本申请实施例提供一种数据处理方法，包括：

获取账户数据；

获取所述账户数据对应的信用数据，其中，所述信用数据适于根据账户的行为数据减少数值；

根据所述信用数据，获取推荐组合，其中，所述推荐组合包括多个推荐对象。

在示例性实施方式中，所述根据所述信用数据，获取推荐组合，可以包括：确定所述信用数据低于第一预设阈值；获取整体价格低于第二预设阈值的推荐组合，其中，所述整体价格根据所述多个推荐对象的价格计算。

在示例性实施方式中，所述根据所述信用数据，获取推荐组合，可以包括：确定所述信用数据低于第一预设阈值，获取所述推荐对象的数目低于第三预设阈值的推荐组合。

在示例性实施方式中，所述信用数据的任一数据范围与所述推荐组合可以存在一对多的对应关系。

在示例性实施方式中，上述方法还可以包括：展示所述推荐组合以及所述推荐组合对应的整体价格，其中，所述整体价格根据所述多个推荐对象的价格计算。

在示例性实施方式中，所述信用数据适于根据账户的行为数据减少数值，可以包括以下至少之一：

若所述账户的行为数据包括一次逃单行为，则所述账户对应的信用数据减少第一数值；

若所述账户的行为数据包括一次恶意评价行为，则所述账户对应的信用数据减少第二数值。

第六方面，本申请实施例提供一种计算设备，包括：存储器和处理器，所述存储器用于存储数据处理程序，所述数据处理程序被所述处理器执行时实现上述第一方面、第二方面、第三方面或第五方面提供的数据处理方法的步骤。

此外，本申请实施例提供一种计算机可读介质，存储有数据处理程序，所述数据处理程序被处理器执行时实现上述第一方面、第二方面、第三方面或第五方面提供的数据处理方法的步骤。

在本申请实施例中，接收点餐对象的点餐请求后，确定点餐对象的用餐特征，并根据用餐特征，确定提供给该点餐对象的推荐菜单。如此，给用户提供合适的推荐菜单，不仅缩短了用户点餐时间，提高了用户体验，而且能够提升商家利益。

在本申请实施例中，确定用餐特征，根据供餐对象的历史点餐数据，确定对应于该用餐特征的至少两个推荐菜单，其中，至少两个推荐菜单对应的该用餐特征的特征值不同。如此，提供多种推荐菜单给用户进行选择，提高了用户体验，而且缩短了用户点餐时间。

在本申请实施例中，接收点餐对象的点餐请求后，确定点餐对象的信誉指数，若点餐对象的信誉指数满足第三条件，则向供餐对象发出提醒消息。如此，通过对点餐对象进行信誉验证，对于可能引起供餐对象损失的点餐对象，对供餐对象进行必要提醒，从而给供餐对象提供安全保障。

在本申请实施例中，根据账户数据对应的信用数据，获取推荐组合；如此，在考量安全性的基础上实现信息推荐，从而提高用户体验。

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

附图说明

图1为本申请实施例提供的一种数据处理方法的流程图；

图2为本申请实施例提供的数据处理方法的一种示例图；

图3为本申请实施例提供的数据处理方法的另一示例图；

图4为本申请实施例提供的数据处理方法的再一示例图；

图5为本申请实施例提供的另一种数据处理方法的流程图；

图6为本申请实施例提供的再一种数据处理方法的流程图；

图7为本申请实施例提供的一种数据处理装置的示意图；

图8为本申请实施例提供的又一种数据处理方法的流程图。

具体实施方式

以下结合附图对本申请实施例进行详细说明，应当理解，以下所说明的实施例仅用于说明和解释本申请，并不用于限定本申请。

需要说明的是，如果不冲突，本申请实施例以及实施例中的各个特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

一些实施方式中，执行数据处理方法的计算设备可包括一个或多个处理器(CPU，Central Processing Unit)、输入/输出接口、网络接口和内存(memory)。

内存可能包括计算机可读介质中的非永久性存储器、随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。内存可能包括模块1，模块2，……，模块N(N为大于2的整数)。

计算机可读介质包括永久性和非永久性、可移动和非可移动存储介质。存储介质可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)，快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

图1为本申请实施例提供的一种数据处理方法的示意图。如图1所示，本实施例提供的数据处理方法，包括：

S101、接收点餐对象的点餐请求后，确定点餐对象的用餐特征；

S102、根据用餐特征，确定提供给点餐对象的推荐菜单。

本实施例提供的数据处理方法，用于实现给点餐对象进行菜单推荐，从而缩短用户点餐时间，提高用户体验，且提升商家利益。

本实施例提供的数据处理方法可以由客户端计算设备(比如，手机、平板电脑等移动终端，或者台式电脑等固定终端)执行，或者可以由服务端计算设备(比如，服务器等)执行。然而，本申请对此并不限定。

示例性地，客户端计算设备可以在接收到点餐请求后，将点餐请求发送给服务端计算设备，服务端计算设备执行S101和S102，并将确定的推荐菜单发送给客户端计算设备，由客户端计算设备将推荐菜单显示给用户。或者，客户端计算设备在接收点餐请求后，执行S101和S102，并将确定的推荐菜单显示给用户。然而，本申请对此并不限定。

示例性地，点餐请求可以至少携带点餐对象标识(ID)、供餐对象ID。其中，点餐对象ID可以包括点餐对象名称或编号；供餐对象ID可以包括供餐对象名称或编号。然而，本申请对此并不限定。本实施例中，点餐对象可以指点餐用户，或者点餐用户在点餐应用或网站登录的用户账户。供餐对象可以指提供餐饮服务的商家，或者商家在点餐应用或网站对应的商家账户。

本实施例中，点餐请求可以由用户使用客户端计算设备(比如，智能手机等)扫描二维码触发，或者，由用户点击客户端计算设备(比如，智能手机，或者点餐平板电脑等)的显示界面上的点餐按钮触发。然而，本申请对此并不限定。

在示例性实施方式中，用餐特征可以包括以下至少之一：用餐人数、消费价位、口味偏好、营养成分。其中，营养成分可以包括能量、蛋白质、脂肪、碳水化合物等的需求量。

示例性地，在S101中，确定点餐对象的用餐特征，可以包括以下至少之一：

根据点餐请求携带的信息，确定点餐对象的用餐特征；比如，点餐请求除了携带点餐对象ID、供餐对象ID外，还可以携带用餐人数、点餐对象本次点餐可承受的消费价位、本次点餐偏好的口味、营养成分等信息；

根据点餐对象的历史点餐数据，确定点餐对象的用餐特征；比如，可以根据点餐请求携带的点餐对象ID，从数据中心获取点餐对象在设定时长内(例如，最近一年或半年内)的所有历史点餐数据，通过分析这些历史点餐数据，确定该点餐对象的消费价位、口味偏好、营养成分等数据；其中，点餐对象的任一条历史点餐数据可以包括：该点餐对象的点餐时间、用餐人数、供餐对象、消费总价、菜单等；或者，可以根据点餐请求携带的点餐对象ID和供餐对象ID，从数据中心获取点餐对象在设定时长内(例如，最近一年或半年内)在该供餐对象ID对应的供餐对象的所有历史点餐数据，通过分析这些历史点餐数据，确定该点餐对象在该供餐对象的消费价位、口味偏好、营养成分等数据；

根据点餐对象的输入信息，确定点餐对象的用餐特征；比如，可以获取用户在点餐设备(比如，智能手机，或商家提供的点菜终端等)的显示界面上输入的用餐人数、口味偏好等数据。

在示例性实施方式中，S102可以包括以下至少之一：

从供餐对象的历史菜单中筛选出符合点餐对象的用餐特征的一个或多个历史菜单，根据筛选出的历史菜单，确定提供给点餐对象的推荐菜单；比如，从筛选出的历史菜单中随机选择一个确定为提供给点餐对象的推荐菜单；

根据对供餐对象的菜品的点评数据，确定供餐对象的推荐菜品；从供餐对象的推荐菜品中筛选出符合点餐对象的用餐特征的菜品组合，将筛选出的菜品组合作为提供给点餐对象的推荐菜单；比如，根据对供餐对象的菜品的点评数据，将好评量满足条件的菜品，确定为推荐菜品，然后从推荐菜品中选择至少两个推荐菜品进行组合，以符合点餐对象的用餐特征(例如，选择出的推荐菜品的总价符合点餐对象的消费价位)。

在示例性实施方式中，用餐特征至少可以包括用餐人数；

S102可以包括：

根据用餐人数以及供餐对象的人均消费费用，计算第一点餐总价；

根据点餐对象的用餐人数，确定供餐对象提供的与该用餐人数对应的推荐菜品种类；

按照设定规则选择推荐菜品种类中的菜品，并根据选择出的菜品的价格，计算第二点餐总价；

根据第一点餐总价和第二点餐总价的比较结果，调整所选择的菜品，直至第一点餐总价和第二点餐总价的差值绝对值满足第一条件(比如小于或等于某一阈值)；

确定提供给点餐对象的推荐菜单为调整后所选择出的菜品组合。

示例性地，按照设定规则选择推荐菜品种类中的菜品，可以包括以下之一：

针对任一种推荐菜品种类，随机选择一种或多种高频菜品，其中，高频菜品为历史点选次数大于或等于阈值的菜品；

在任一种推荐菜品种类中选择推荐菜品，其中，推荐菜品由供餐对象预设，或者，根据菜品点评数据确定；

针对任一种推荐菜品种类，选择其中价格满足第二条件的菜品，比如，该推荐菜品种类中价格居中的菜品。

在示例性实施方式中，本实施例的方法还可以包括：

接收点餐对象的点餐请求后，确定点餐对象的信誉指数；

若点餐对象的信誉指数满足第三条件，则向供餐对象发出提醒消息。

比如，若信誉指数越大指示点餐对象的信誉越高，信誉指数越小指示点餐对象的信誉越低，则点餐对象的信誉指数小于或等于某一阈值，可以向供餐对象发出提醒消息；或者，若信誉指数越小指示点餐对象的信誉越高，信誉指数越大指示点餐对象的信誉越低，则点餐对象的信誉指数大于或等于某一阈值，可以向供餐对象发出提醒消息。换言之，在点餐对象的信誉较差时，向供餐对象发出提醒消息，以便提醒供餐对象注意该点餐对象出现逃单或恶意行为的概率较高。

本示例中，可以将提醒消息发送至与供餐对象ID关联的终端设备(比如，智能手机等)上。

在本示例性实施方式中，若点餐对象的信誉指数满足第三条件，则根据用餐特征，确定提供给点餐对象的推荐菜单，可以包括：

根据点餐对象的用餐特征和信誉指数，确定提供给点餐对象的推荐菜单。

比如，在点餐对象的信誉较差时，可以调整点餐对象的用餐特征(例如，减少用餐人数、降低消费价位)，然后根据调整后的用餐特征确定推荐菜单。相较于根据点餐对象的未调整的用餐特征确定的推荐菜单，在点餐对象的信誉较差时，确定的推荐菜单的总价较低、菜品较少。

在本示例性实施方式中，确定点餐对象的信誉指数，可以包括：

根据点餐对象的历史点餐数据，确定点餐对象的信誉指数特征；根据点餐对象的信誉指数特征，确定点餐对象的信誉指数；比如，采用预先训练的分类器模型处理点餐对象的信誉指数特征，得到点餐对象的信誉指数。

下面通过多个示例对本申请进行说明。

图2为本申请实施例提供的数据处理方法的一种示例图。如图2所示，本实施例以云端的服务器确定推荐菜单为例进行说明，用户可以通过终端设备(比如，智能手机)进行点餐操作。其中，服务器的数据中心存储有点餐对象(用户)和供餐对象(商家)的历史点餐数据；数据中心记录的每条历史点餐数据例如可以包括：点餐对象ID、供餐对象ID、点餐时间、用餐人数、菜单、价格等信息。

如图2所示，本实施例包括以下步骤：

S201、用户(点餐对象)通过终端设备扫描供餐对象(商家)提供的点餐二维码。

S202、终端设备向服务器发送点餐请求；示例性地，点餐请求可以携带点餐对象ID、供餐对象ID；其中，终端设备在扫描点餐二维码之后，可以显示点餐界面，以便用户输入用餐人数、消费价位等用餐特征数据，终端设备可以将用户在点餐界面输入的数据发送给服务器。

然而，本申请对此并不限定；在其他实现方式中，用户可以在终端设备的点餐显示界面上设置用餐特征等数据，然后点击点餐按钮触发终端设备发送点餐请求；其中，点餐请求可以包括以下信息：点餐对象ID、供餐对象ID、所设置的用餐特征(比如，用餐人数、消费价位等)。

S203、服务器接收到点餐请求后，确定给点餐对象提供的推荐菜单。

在本示例中，以服务器根据用餐人数确定推荐菜单为例进行说明。服务器可以对供餐对象的历史点餐数据进行分析训练，确定供餐对象提供的与不同用餐人数对应的推荐菜品种类。

本示例中的分析训练过程可以包括：

针对一个供餐对象，将该供餐对象的菜品种类定义为以下八种类型：商家上新、特色(招牌)菜、凉菜、荤菜、蔬菜、汤和甜点，分别标记为t₁、t₂、t₃、…、t₈；其中，在该供餐对象的历史菜单中，可以对每一个菜品均进行种类标记；

针对任一供餐对象，获取数据中心存储的历史点餐数据，将菜单中的菜品转换为菜品种类，可以按照以下方式定义每个历史菜单：R＝{price，T}；其中，price为菜单总价，T为菜单的菜品种类集合，T内的菜品种类可以重复；

根据供餐对象的人均消费费用，将R中price转化为用餐人数(PersonCount)，即标记菜单为R’＝{PersonCount，T}；其中，供餐对象的人均消费费用可以根据设定时长内供餐对象的总菜单收费与总用餐人数的比值确定；

将PersonCount作为类别对菜单进行分类，然后针对任一PersonCount对应的所有菜单，统计这些菜单的T中菜品种类t_i的出现次数，i的取值为1至8中的整数，并且统计所有类别出现的总数，记为total，定义种类平均数t＝total/|T|，|T|表示菜单菜品种类集合中的菜品种类数目；本示例中，将出现次数超过t的菜品种类，确定为高频菜品种类(即上述的推荐菜品种类)，可以记为Main＝{t_i}；将出现次数未超过t的菜品种类，确定为低频菜品种类，可以记为Min＝{t_i}。其中，还可以针对任一菜品种类，统计该菜品种类t_i中任一菜品的出现次数，并将出现次数超过点菜平均数的菜品定义为高频菜品，记为MainMenuT_i＝{C₁，C₂，…，C_N}，其中，N为该菜品种类t_i的高频菜品的数目；其中，点菜平均数的计算方式可以参照种类平均数的计算方式，故于此不再赘述。

需要说明的是，上述分析训练过程可以定时执行，或者周期执行，或者在供餐对象推出新菜品之后执行。然而，本申请对此并不限定。

在本示例中，服务器根据点餐对象的用餐人数以及供餐对象的人均消费费用的乘积，可以计算第一点餐总价P；根据点餐对象的用餐人数，以及上述分析训练得到的用餐人数对应的推荐菜品种类，可以确定与该用餐人数对应的推荐菜品种类，再从每个推荐菜品种类随机选择一种高频菜品，计算选择出的所有菜品的价格总和为第二点餐总价P’；比较P和P’，如果P大于P’，且P-P’大于第一阈值，则从推荐菜品种类中随机选择一种或多种低频菜品，直至P-P’小于或等于第二阈值；其中，第二阈值小于第一阈值；如果P小于P’，且P’-P大于第一阈值，则随机删除一种或多种已选择的高频菜品，直至P’-P小于或等于第二阈值；如果P＝P’，则不再调整已选择的菜品；将最终选择出的菜品的组合确定为推荐菜单。

然而，本申请对此并不限定。在其他实现方式中，在确定与用餐人数对应的推荐菜品种类之后，可以从每个推荐菜品种类中选择价格满足第二条件的菜品，比如价格居中的菜品，或者价格在预设范围内的菜品；或者，可以从每个推荐菜品种类中选择推荐菜品，比如，每个推荐菜品种类中均有供餐对象预设的推荐菜品(比如，新菜)，或者也可以根据菜品的历史点评数据，将好评量满足条件(比如，好评量大于或等于某一阈值)的菜品确定为推荐菜品。

另外，在其他实现方式中，服务器可以根据用餐人数，从供餐对象的历史点餐数据中查找与该用餐人数匹配的历史菜单，然后随机选择一个历史菜单作为推荐菜单；或者，可以根据用餐人数，从供餐对象的历史点餐数据中查找与该用餐人数匹配的历史菜单，然后选择菜单总价居中的一个历史菜单作为推荐菜单。

另外，在其他实现方式中，服务器可以根据用餐人数，从供餐对象的历史点餐数据中查找与该用餐人数匹配的历史菜单，然后根据这些历史菜单对应的菜品点评数据，确定推荐菜品，然后随机选择多种推荐菜品的组合作为推荐菜单，或者，选择总价满足一定条件的多种推荐菜品的组合作为推荐菜单。

在其他实现方式中，服务器可以根据点餐对象的历史点餐数据，确定点餐对象每餐的营养成分(比如，每餐所需摄入的平均能量等)，然后根据营养成分，进行菜品选择，进而确定推荐菜单。

在其他实现方式中，服务器还可以根据点餐对象的历史点餐数据，确定点餐对象的口味偏好，然后根据口味偏好，选择对应的菜品，确定推荐菜单。

在其他实现方式中，服务器可以根据用餐人数、消费价位、口味偏好以及营养成分中的至少两项，进行菜品选择，然后确定推荐菜单。

S204、服务器将确定的推荐菜单发送给终端设备。

S205、终端设备向用户展示推荐菜单，用户可以基于推荐菜单进行修改，并确认最终的菜单。

S206、终端设备将最终菜单发送给服务器；服务器可以将最终菜单发送给供餐对象对应的终端设备，以便供餐对象按照该菜单进行制作。

S207、用户用餐完毕之后，可以在终端设备进行在线支付和用餐评价。

S208、终端设备将完整点餐数据和评价数据发送到服务器，由服务器的数据中心进行存储。

同样地，供餐对象在用户用餐完毕之后，可以提交评价数据至服务器，由服务器的数据中心进行存储。其中，供餐对象的评价数据可以包括用户是否存在逃单，或是否存在恶意行为之类的信息。

需要说明的是，在其他实现方式中，终端设备接收到点餐请求后，可以从服务器获取相关的数据，然后在本端执行S203确定推荐菜单，并将确定的推荐菜单显示给用户。

图3为本申请实施例提供的数据处理方法的另一示例图。如图3所示，本实施例以云端的服务器进行安全验证和确定推荐菜单为例进行说明。其中，服务器的数据中心存储有点餐对象(用户)和供餐对象(商家)的历史点餐数据；数据中心记录的每条历史点餐数据例如可以包括：点餐对象ID、供餐对象ID、点餐时间、用餐人数、菜单、价格等信息。

图3所示的示例与图2所示的示例的区别在于：服务器在接收点餐请求后，还会确定点餐对象的信誉指数，并根据信誉指数，确定是否向供餐对象发送提醒消息。

如图3所示，本实施例包括以下步骤：

S301、用户(点餐对象)通过第一终端设备扫描供餐对象(商家)提供的点餐二维码；

S302、第一终端设备向服务器发送点餐请求。

关于S301和S302的说明可以参照图2中的S201和S202，故于此不再赘述。

S303、服务器确定点餐对象的信誉指数，并判断信誉指数是否满足第三条件。

本示例中，根据点餐对象的历史点餐数据，确定点餐对象的信誉指数特征；根据点餐对象的信誉指数特征以及基于历史数据训练得到的分类器模型，确定点餐对象的信誉指数。

本示例中，信誉指数特征可以包括以下维度：用户的芝麻信用分数等级(ZhiMaScore)；用户年龄分层(UserAge)；用户在设定时长(比如，最近一年或半年)内平均每星期扫码点餐次数(UserWeekTimes)；用户在外扫码点餐总数(UserTotalTimes)；用户最近一周扫码点餐次数(UserLatestWeekTimes)；用户被商家举报次数(UserReportedTimes)(比如，用户有逃单或其他恶意行为被商家举报的次数)；用户举报商家次数(UserReportTimes)；用户在设定时长内的点餐平均总价(TotalPrice)；用户在设定时长内每次平均点餐菜品数(PlateCount)；用户最经常点餐的商家等级或者用户的历史点餐商家中出现频率最高的商家等级(SellerLevel)。然而，本申请对此并不限定。

本示例中，分类器模型的构建过程可以包括：

获取商家的举报数据及历史点餐数据，进行数据预处理，按照一定规则识别有效数据，并给识别出的有效数据，标记Label；其中，可以定义用户U＝{Label，UserFeature}，其中，Label的取值范围为{0，1}，0表示用户正常买单，1表示用户逃单或者存在其它恶意行为等；UserFeature表示用户的信誉指数特征的取值；

采用支持向量机(SVM，Support Vector Machine)对标记数据进行训练，生成分类器模型；然而，本申请对此并不限定。在其他实现方式中，也可以采用朴素贝叶斯方法等其他分类算法对标记数据进行训练，生成分类器模型。

在本示例中，服务器接收到点餐请求后，可以其中携带的点餐对象ID从数据中心获取对应的历史点餐数据，然后整理得到点餐对象的信誉指数特征，将点餐对象的信誉指数特征输入训练得到的分类器模型，得到输出的信誉指数。本示例中，分类器模型输出的信誉指数用于指示用户信誉较差的概率。然后，服务器比较得到的信誉指数以及阈值，判断信誉指数是否满足第三条件(即信誉指数是否大于或等于该阈值)；若满足第三条件，则执行S304，即发送提醒消息到供餐对象的第二终端设备，以提醒供餐对象该点餐对象的信誉较差。

S305、服务器确定提供给点餐对象的推荐菜单。

本示例中，在S303之后，不管点餐对象的信誉指数是否满足第三条件，服务器均会执行S305。

关于本步骤的说明可以参照图2中对S203的描述，故于此不再赘述。

S306、服务器将确定的推荐菜单发送给第一终端设备。

S307、第一终端设备向用户展示推荐菜单，用户可以基于推荐菜单进行修改，并确认最终的菜单。

S308、第一终端设备将最终菜单发送给服务器；

S309、服务器可以将最终菜单发送给供餐对象对应的第二终端设备，以便供餐对象按照该菜单进行制作。

S310、用户用餐完毕之后，可以在第一终端设备进行在线支付和用餐评价。

S311、第一终端设备将完整点餐数据和评价数据发送到服务器，由服务器的数据中心进行存储。

S312、第二终端设备将供餐对象的评价数据发送到服务器，由服务器的数据中心进行存储。

需要说明的是，在其他实现方式中，第一终端设备接收到点餐请求后，可以从服务器获取相关的数据以及分类器模型，然后在本端执行信誉指数确定和验证以及确定推荐菜单，并将确定的推荐菜单显示给用户。其中，第一终端设备可以在信誉指数满足第三条件时，将提醒消息通过服务器发送给第二终端设备，或者直接发送给第二终端设备。然而，本申请对此并不限定。

图4为本申请实施例提供的数据处理方法的另一示例图。如图4所示，本实施例以云端的服务器进行安全验证和确定推荐菜单为例进行说明。图4所示的示例与图3所示的示例的区别在于：服务器确定点餐对象的信誉指数满足第三条件时，根据点餐对象的用餐特征和信誉指数，确定推荐菜单。

本示例的S401至S404以及S406至S412可以参照图3中的S301至S304以及S306至S312，故于此不再赘述。

本示例中，S405、服务器根据点餐对象的信誉指数和用餐特征，确定推荐菜单。在本步骤中，若信誉指数满足第三条件(即点餐对象的信誉较差)，则可以降低用餐特征的取值，比如，消费价位为200元，则降低后可以为150元；比如，用餐人数为6人，则降低后可以为4人，然后根据降低后的用餐特征，确定推荐菜单。或者，可以根据用餐特征确定推荐菜单后，在确定的推荐菜单的基础上减少一个或多个菜品，得到最终的推荐菜单。然而，本申请对此并不限定。

图5为本申请实施例提供的另一数据处理方法的流程图。如图5所示，本实施例提供的数据处理方法，包括：

S501、确定用餐特征；

S502、根据供餐对象的历史点餐数据，确定对应于用餐特征的至少两个推荐菜单；其中，至少两个推荐菜单对应的用餐特征的特征值不同。

本实施例提供的数据处理方法可以由服务端计算设备(比如，服务器等)，或者，客户端计算设备(比如，平板电脑等移动终端，或者台式电脑等固定终端)执行。然而，本申请对此并不限定。

示例性地，用餐特征可以包括以下至少之一：用餐人数、消费价位、口味偏好、营养成分。

示例性地，本实施例可以由商家提供的点餐电子设备执行，商家或用户可以在点餐电子设备上配置按照用餐人数提供推荐菜单，则点餐电子设备可以基于商家的历史点餐数据，确定不同用餐人数对应的推荐菜单；比如，可以确定2至3人用餐时的推荐菜单、4至6人用餐时的推荐菜单、7至10人用餐时的推荐菜单以及大于10人用餐时的推荐菜单；或者，可以确定消费价位在100元的推荐菜单、消费价位在200元的推荐菜单、消费价位在500元的推荐菜单；点餐电子设备可以在显示界面显示这些推荐菜单的信息；则用户可以根据实际用餐人数选择对应的推荐菜单，并基于推荐菜单进行修改确认最终菜单，从而缩短了用户点餐时间，提高了用户体验。

图6为本申请实施例提供的另一数据处理方法的流程图。如图6所示，本实施例提供的数据处理方法，包括：

S601、接收点餐对象的点餐请求后，确定点餐对象的信誉指数；

S602、若点餐对象的信誉指数满足第三条件，则向供餐对象发出提醒消息。即点餐对象的信誉较差时，向供餐对象发出提醒消息。

示例性地，S601中，确定点餐对象的信誉指数，可以包括：

根据点餐对象的历史点餐数据，确定点餐对象的信誉指数特征；

根据点餐对象的信誉指数特征，确定点餐对象的信誉指数。

关于本实施例提供的方法的相关说明可以参照图3对应示例的说明，故于此不再赘述。

此外，本申请实施例还提供一种显示方法，包括：提供一个显示界面，显示界面用于显示一个或多个推荐菜单；其中，推荐菜单包括多种菜品以及多种菜品对应的整体价格，整体价格根据多种菜品的价格计算得到。示例性地，推荐菜单可以包括：多种菜品的名称、图片、营养成分、价格以及多个菜品对应的整体价格。然而，本申请对此并不限定。

比如，商家提供的点餐电子设备的显示界面可以预先提供多个推荐菜单，以便用户根据实际需求进行选择；或者，用户的终端设备(比如智能手机上)提交点餐请求后，会在显示界面上显示一个最优的推荐菜单，以便用户基于该推荐菜单进行修改确认最终菜单，从而方便用户操作，提高用户体验。

示例性地，显示界面还可以用于提供点餐信息输入界面。比如，商家提供的点餐电子设备的显示界面上还可以提供点餐信息输入界面，用户可以在该输入界面选择按照哪种用餐特征查看推荐菜单，例如，用户选择按照用餐人数查看推荐菜单，则点餐电子设备可以将不同用餐人数对应的推荐菜单显示在显示界面上，以便用户选择；或者，用户可以在自己的终端设备(比如，智能手机)的点餐信息输入界面上输入本次的用餐人数，然后点击确认后提交点餐请求，然后终端设备会在显示界面提供根据用餐人数确定的最优的推荐菜单，以便用户基于该推荐菜单进行后续操作。

如图7所示，本申请实施例还提供一种数据处理装置，包括：

第一处理模块701，配置为接收点餐对象的点餐请求后，确定点餐对象的用餐特征；

第二处理模块702，配置为根据用餐特征，确定提供给点餐对象的推荐菜单。

示例性地，用餐特征可以包括以下至少之一：用餐人数、消费价位、口味偏好、营养成分。

关于本实施例提供的装置的相关说明可以参照图1对应的方法实施例的描述，故于此不再赘述。

图8为本申请实施例提供的又一种数据处理方法的流程图。如图8所示，本实施例提供的数据处理方法，包括：

S801、获取账户数据；

S802、获取账户数据对应的信用数据，其中，信用数据适于根据账户的行为数据减少数值；

S803、根据信用数据，获取推荐组合，其中，推荐组合包括多个推荐对象。

本实施例提供的数据处理方法可以由客户端计算设备(比如，手机、平板电脑等移动终端，或者台式电脑等固定终端)执行，或者可以由服务端计算设备(比如，服务器等)执行。然而，本申请对此并不限定。

本实施例中，推荐对象可以包括推荐菜品，推荐组合可以包括推荐菜单。本实施例提供的数据处理方法，可以用于实现菜单推荐，从而缩短用户点餐时间，提高用户体验，且提升商家利益。然而，本申请对此并不限定。

本实施例中，在S801中，可以根据接收到的点餐请求携带的点餐对象ID，获取对应的账户数据；示例性地，账户数据可以包括：点餐对象ID、历史点餐数据等。然而，本申请对此并不限定。

本实施例中，信用数据用于指示账户的信誉好坏程度。示例性地，大于或等于第一预设阈值的信用数据用于指示账户的信誉良好，小于第一预设阈值的信用数据用于指示账户的信誉不佳。

示例性地，若账户的行为数据包括一次逃单行为，则账户对应的信用数据减少第一数值；若账户的行为数据包括一次恶意评价行为，则账户对应的信用数据减少第二数值。比如，初始的信用数据为100，则根据设定时长内账户的行为数据是否包括逃单行为、恶意评价行为，以及这些行为的次数，确定信用数据需要减少的数值，以得到根据账户的行为数据更新后的信用数据。

示例性地，账户对应的信用数据可以包括：根据账户的信誉指数特征确定的信誉指数。比如，采用预先训练的分类器模型处理账户的信誉指数特征，得到对应的信誉指数。其中，信誉指数越大指示账户的信誉越高，信誉指数越小指示账户的信誉越低。信誉指数特征可以根据账户的行为数据得到，其中，账户的恶意行为(比如，逃单行为、恶意评价行为等)越多，则信誉指数越低。

在示例性实施方式中，S803可以包括：确定信用数据低于第一预设阈值；获取整体价格低于第二预设阈值的推荐组合，其中，整体价格根据多个推荐对象的价格计算。

其中，在确定信用数据低于第一预设阈值时，表明账户的信誉不佳，则获取整体价格低于第二预设阈值的推荐组合。比如，在账户的信誉不佳时，根据账户的历史消费价位确定推荐菜单的整体价格之后，将整体价格调整至小于第二预设阈值，例如，通过减少推荐组合中的推荐对象或者更换价格较低的推荐对象来调整整体价格；然后，确定调整后的推荐组合。

在示例性实施方式中，S803可以包括：确定信用数据低于第一预设阈值，获取推荐对象的数目低于第三预设阈值的推荐组合。

其中，在确定信用数据低于第一预设阈值时，表明账户的信誉不佳，则获取推荐对象的数目低于第三预设阈值的推荐组合。比如，在账户的信誉不佳时，根据账户的历史点餐数据确定推荐组合中的推荐对象的数目之后，减少推荐对象的数目，使得低于第三预设阈值，然后，确定调整后的推荐组合。

示例性地，确定信用数据低于第一预设阈值，可以获取整体价格低于第二预设阈值且推荐对象的数目低于第三预设阈值的推荐组合。然而，本申请对此并不限定。

在示例性实施方式中，信用数据的任一数据范围与推荐组合可以存在一对多的对应关系。比如，可以预先配置用餐人数为1至3人对应的推荐组合，用餐人数为4至6人对应的推荐组合，用餐人数为7至10人对应的推荐组合以及用餐人数为大于10人的推荐组合；然后可以设置信用数据的任一数据范围与上述四个推荐组合的对应关系；在确定账户数据对应的信用数据之后，可以根据该信用数据所属的数据范围以及账户当前的用餐人数，获取对应的推荐组合。或者，信用数据的任一数据范围可以对应根据用餐人数确定的推荐组合以及根据消费价位确定的推荐组合，在确定账户数据对应的信用数据之后，根据该信用数据所属的数据范围，获取对应的推荐组合，以提供给用户选择合适的推荐组合。然而，本申请对此并不限定。

在示例性实施方式中，在S803之后，本实施例的方法还可以包括：

展示推荐组合以及推荐组合对应的整体价格，其中，整体价格根据多个推荐对象的价格计算。

比如，可以在显示界面上展示推荐组合中每个推荐对象的名称、图片、价格等信息以及推荐组合对应的整体价格。

需要说明的是，本实施例中的第一预设阈值、第二预设阈值、第三预设阈值、第一数值以及第二数值可以根据实际应用场景进行设定。本申请对此并不限定。

本实施例中，基于信用数据实现信息推荐，从而在考量安全性的基础上提高用户体验。

此外，本申请实施例还提供一种计算设备，包括：存储器和处理器，存储器用于存储数据处理程序，数据处理程序被处理器执行时实现上述任一实施例提供的数据处理方法的步骤。

其中，处理器可以包括但不限于微处理器(MCU，Microcontroller Unit)或可编程逻辑器件(FPGA，Field Programmable Gate Array)等的处理装置。存储器可用于存储应用软件的软件程序以及模块，如本实施例中的数据处理方法对应的程序指令或模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的数据处理方法。存储器可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可包括相对于第一处理器远程设置的存储器，这些远程存储器可以通过网络连接至上述计算设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

示例性地，上述计算设备还可以包括通信单元；通信单元可以经由一个网络接收或者发送数据。在一个实例中，通信单元可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通信。

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

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块或单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块或单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

以上显示和描述了本申请的基本原理和主要特征和本申请的优点。本申请不受上述实施例的限制，上述实施例和说明书中描述的只是说明本申请的原理，在不脱离本申请精神和范围的前提下，本申请还会有各种变化和改进，这些变化和改进都落入要求保护的本申请范围内。

Claims (23)

1.一种数据处理方法，其特征在于，包括：

接收点餐对象的点餐请求后，确定所述点餐对象的用餐特征；

根据所述用餐特征，确定提供给所述点餐对象的推荐菜单。

2.根据权利要求1所述的方法，其特征在于，所述用餐特征包括以下至少之一：用餐人数、消费价位、口味偏好、营养成分。

3.根据权利要求1所述的方法，其特征在于，所述确定点餐对象的用餐特征，包括以下至少之一：

根据所述点餐请求携带的信息，确定所述点餐对象的用餐特征；

根据所述点餐对象的历史点餐数据，确定所述点餐对象的用餐特征；

根据所述点餐对象的输入信息，确定所述点餐对象的用餐特征。

4.根据权利要求1所述的方法，其特征在于，所述根据所述用餐特征，确定提供给所述点餐对象的推荐菜单，包括以下至少之一：

从供餐对象的历史菜单中筛选出符合所述点餐对象的用餐特征的一个或多个历史菜单，根据筛选出的历史菜单，确定提供给所述点餐对象的推荐菜单；

根据对供餐对象的菜品的点评数据，确定所述供餐对象的推荐菜品；从所述供餐对象的推荐菜品中筛选出符合所述点餐对象的用餐特征的菜品组合，将所述筛选出的菜品组合作为提供给所述点餐对象的推荐菜单。

5.根据权利要求2所述的方法，其特征在于，所述用餐特征至少包括用餐人数；所述根据所述用餐特征，确定提供给所述点餐对象的推荐菜单，包括：

根据所述用餐人数以及供餐对象的人均消费费用，计算第一点餐总价；

根据所述点餐对象的用餐人数，确定所述供餐对象提供的与所述用餐人数对应的推荐菜品种类；

按照设定规则选择所述推荐菜品种类中的菜品，并根据选择出的菜品的价格，计算第二点餐总价；

根据所述第一点餐总价和所述第二点餐总价的比较结果，调整所选择的菜品，直至所述第一点餐总价和所述第二点餐总价的差值绝对值满足第一条件；

确定提供给所述点餐对象的推荐菜单为调整后所选择出的菜品组合。

6.根据权利要求5所述的方法，其特征在于，所述按照设定规则选择所述推荐菜品种类中的菜品，包括以下之一：

针对任一种推荐菜品种类，随机选择一种或多种高频菜品，其中，所述高频菜品为历史点选次数大于或等于阈值的菜品；

在任一种推荐菜品种类中选择推荐菜品，其中，所述推荐菜品由所述供餐对象预设，或者，根据菜品点评数据确定；

针对任一种推荐菜品种类，选择其中价格满足第二条件的菜品。

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

接收点餐对象的点餐请求后，确定所述点餐对象的信誉指数；

若所述点餐对象的信誉指数满足第三条件，则向供餐对象发出提醒消息。

8.根据权利要求7所述的方法，其特征在于，若所述点餐对象的信誉指数满足第三条件，则根据所述用餐特征，确定提供给所述点餐对象的推荐菜单，包括：

根据所述点餐对象的用餐特征和信誉指数，确定提供给所述点餐对象的推荐菜单。

9.根据权利要求7所述的方法，其特征在于，所述确定所述点餐对象的信誉指数，包括：

根据所述点餐对象的历史点餐数据，确定所述点餐对象的信誉指数特征；

根据所述点餐对象的信誉指数特征，确定所述点餐对象的信誉指数。

10.一种数据处理方法，其特征在于，包括：

确定用餐特征；

根据供餐对象的历史点餐数据，确定对应于所述用餐特征的至少两个推荐菜单；其中，所述至少两个推荐菜单对应的所述用餐特征的特征值不同。

11.根据权利要求10所述的方法，其特征在于，所述用餐特征包括以下至少之一：用餐人数、消费价位、口味偏好、营养成分。

12.一种数据处理方法，其特征在于，包括：

接收点餐对象的点餐请求后，确定所述点餐对象的信誉指数；

若所述点餐对象的信誉指数满足第三条件，则向供餐对象发出提醒消息。

13.根据权利要求12所述的方法，其特征在于，所述确定所述点餐对象的信誉指数，包括：

根据所述点餐对象的历史点餐数据，确定所述点餐对象的信誉指数特征；

根据所述点餐对象的信誉指数特征，确定所述点餐对象的信誉指数。

14.一种显示方法，其特征在于，包括：

提供一个显示界面，所述显示界面用于显示一个或多个推荐菜单；

其中，所述推荐菜单包括多种菜品以及所述多种菜品对应的整体价格；所述整体价格根据所述多种菜品的价格计算得到。

15.根据权利要求14所述的方法，其特征在于，所述显示界面还用于提供点餐信息输入界面。

16.一种计算设备，其特征在于，包括：存储器和处理器，所述存储器用于存储数据处理程序，所述数据处理程序被所述处理器执行时实现如权利要求1至9中任一项所述的数据处理方法的步骤。

17.一种计算机可读介质，其特征在于，存储有数据处理程序，所述数据处理程序被处理器执行时实现如权利要求1至9中任一项所述的数据处理方法的步骤。

18.一种数据处理方法，其特征在于，包括：

获取账户数据；

获取所述账户数据对应的信用数据，其中，所述信用数据适于根据账户的行为数据减少数值；

根据所述信用数据，获取推荐组合，其中，所述推荐组合包括多个推荐对象。

19.根据权利要求18所述的方法，其特征在于，所述根据所述信用数据，获取推荐组合，包括：

确定所述信用数据低于第一预设阈值；

获取整体价格低于第二预设阈值的推荐组合，其中，所述整体价格根据所述多个推荐对象的价格计算。

20.根据权利要求18所述的方法，其特征在于，所述根据所述信用数据，获取推荐组合，包括：

确定所述信用数据低于第一预设阈值；

获取所述推荐对象的数目低于第三预设阈值的推荐组合。

21.根据权利要求18所述的数方法，其特征在于，所述信用数据的任一数据范围与所述推荐组合存在一对多的对应关系。

22.根据权利要求18所述的方法，其特征在于，所述方法还包括：展示所述推荐组合以及所述推荐组合对应的整体价格，其中，所述整体价格根据所述多个推荐对象的价格计算。

23.根据权利要求18所述的方法，其特征在于，所述信用数据适于根据账户的行为数据减少数值，包括以下至少之一：

若所述账户的行为数据包括一次逃单行为，则所述账户对应的信用数据减少第一数值；

若所述账户的行为数据包括一次恶意评价行为，则所述账户对应的信用数据减少第二数值。