电子券的处理方法、电子券服务器、电子设备及存储介质

摘要

本申请提供了一种电子券的处理方法、电子券服务器、电子设备及存储介质，该方法应用于电子券服务器，该电子券的处理方法包括：获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。本申请通过用户在电子券创建界面输入的至少一个电子券的发券规则，为用户确定目标发券人员，不需要重新开发数仓，减小时间成本。

说明书

技术领域

本发明涉及互联网技术领域，具体而言，涉及电子券的处理方法、电子券服务器、电子设备及存储介质。

背景技术

随着互联网的发展，线上店铺越来越多，为了线上店铺的发展，大多数线上店铺会提供很多电子券。

现有技术中，店铺用户会提前设定完成需要发放电子券的目标人群，并将该目标人群存储到数仓中，然后将电子券发送给数仓中的目标人群。如果想要修改目标人群，则需要重新开发数仓中的目标人群，时间成本较高。

发明内容

有鉴于此，本申请的目的在于提供一种电子券的处理方法、电子券服务器、电子设备及存储介质，能够根据用户在电子券创建界面输入的至少一个电子券的发券规则，为用户确定目标发券人员，不需要重新开发数仓，减小时间成本。

第一方面，本申请实施例提供了一种电子券的处理方法，该电子券的处理方法包括：

获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；

将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；

针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。

在一种可能的实施方式中，该方法还包括：

获取用户在电子券发放界面输入的发放周期；

按照发放周期将电子券发送给目标发券人员。

在一种可能的实施方式中，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员，包括：

将符合电子券的发券规则的发券人员信息确定为初始发券人员；

从电子券数据库中获取与初始发券人员对应的已拥有电子券；

若初始发券人员对应的拥有电子券中，不包含电子券的初始发券人员确定为目标发券人员。

在一种可能的实施方式中，电子券的发券规则包括至少一个发券指标及对应的阈值；发券人员信息中包括至少一个发券指标及对应的数值；从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员，包括：

针对每一个发券人员信息，统计发券人员信息中发券指标的数值符合发券规则中与发券指标对应的阈值的发券指标的个数，得到发券人员信息对应的符合数量；

根据发券人员信息对应的符合数量，确定目标发券人员。

在一种可能的实施方式中，根据发券人员信息对应的符合数量，确定目标发券人员，包括：

判断发券人员信息对应的符合数量是否大于预设数量；

若发券人员信息对应的符合数量大于预设数量，则将发券人员信息对应的发券人员确定为目标发券人员。

第二方面，本申请实施例还提供了一种电子券服务器，该电子券服务器包括：

获取模块，用于获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；

发送模块，用于将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；

确定模块，用于针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。

在一种可能的实施方式中，电子券服务器还包括：

获取模块，还用于获取用户在电子券发放界面输入的发放周期；

发送模块，还用于按照发放周期将电子券发送给目标发券人员。

在一种可能的实施方式中，确定模块，具体用于：将符合电子券的发券规则的发券人员信息确定为初始发券人员；从电子券数据库中获取与初始发券人员对应的已拥有电子券；若初始发券人员对应的拥有电子券中，不包含电子券的初始发券人员确定为目标发券人员。

在一种可能的实施方式中，电子券的发券规则包括至少一个发券指标及对应的阈值；发券人员信息中包括至少一个发券指标及对应的数值；确定模块，具体用于针对每一个发券人员信息，统计发券人员信息中发券指标的数值符合发券规则中与发券指标对应的阈值的发券指标的个数，得到发券人员信息对应的符合数量；根据发券人员信息对应的符合数量，确定目标发券人员。

在一种可能的实施方式中，确定模块，具体用于判断发券人员信息对应的符合数量是否大于预设数量；若发券人员信息对应的符合数量大于预设数量，则将发券人员信息对应的发券人员确定为目标发券人员。

第三方面，本申请实施例还提供了一种电子设备，包括：处理器、存储介质和总线，存储介质存储有处理器可执行的机器可读指令，当电子设备运行时，处理器与存储介质之间通过总线通信，处理器执行机器可读指令，以执行如第一方面任一项电子券的处理方法的步骤。

第四方面，本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器运行时执行如第一方面任一项电子券的处理方法的步骤。

本申请实施例提供了一种电子券的处理方法、电子券服务器、电子设备及存储介质，该方法应用于电子券服务器，该电子券的处理方法包括：获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。本申请通过用户在电子券创建界面输入的至少一个电子券的发券规则，为用户确定目标发券人员，不需要重新开发数仓，减小时间成本。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本申请实施例提供的一种电子券的处理方法的流程图；

图2示出了本申请实施例提供的另一种电子券的处理方法的流程图；

图3示出了本申请实施例提供的另一种电子券的处理方法的流程图；

图4示出了本申请实施例提供的一种电子券服务器的结构示意图；

图5示出了本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了使得本领域技术人员能够使用本申请内容，结合特定应用场景“互联网技术领域”，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。虽然本申请主要围绕“互联网技术领域”进行描述，但是应该理解，这仅是一个示例性实施例。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

下面对本申请实施例提供的一种电子券的处理方法进行详细说明。

参照图1所示，为本申请实施例提供的一种电子券的处理方法的流程示意图，该方法应用于电子券服务器，该电子券的处理方法包括：

S101、获取用户在电子券创建界面输入的至少一个电子券的发券规则。

S102、将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息。

S103、针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。

下面对本申请实施例示例性的各步骤进行说明：

S101、获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；

在本申请实施方式中，用户在电子券创建界面输入至少一个电子券的发券规则，还会输入电子券的优惠内容。电子券的发券规则中包括至少一个发券指标及对应的阈值。发券指标可以为“近7个工作日登陆天数”、“近7个工作日大厅搜索次数”、“信用分”等。“近7个工作日登陆天数”对应的阈值可以为大于等于3等，“近7个工作日大厅搜索次数”对应的阈值可以为大于10，“信用分”对应的阈值可以为大于600等等，发券指标和阈值不做具体限定，可以根据实际情况而定。

S102、将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息。

在本申请实施方式中，人员信息数据库中对应存储有发券人员标识、至少一个发券指标及对应的数值。发券人员指的是该用户店铺中的所有客户。

其中，发券人员信息中包括至少一个发券指标及对应的数值。

S103、针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。

具体地，针对每一个发券人员信息，统计发券人员信息中发券指标的数值符合发券规则中与发券指标对应的阈值的发券指标的个数，得到发券人员信息对应的符合数量。

在本申请实施方式中，发券规则中有多个发券指标，针对每一个发券指标，将发券人员信息中发券指标的数值与发券指标对应的阈值的发券指标的个数进行对比，得到发券人员信息对应的符合数量。

例如，发券规则中包括三个发券指标及对应的阈值，第一个发券指标及对应的阈值为“近7个工作日登陆天数大于等于3”；第二个发券指标及对应的阈值为“近7个工作日大厅搜索次数大于10”；第二个发券指标及对应的阈值为“信用分大于600”。发券人员信息的近7个工作日登陆天数为5，近7个工作日大厅搜索次数为8，信用分为700。

将第一个发券指标进行比对，发券人员信息的近7个工作日登陆天数5大于等于第一个发券指标对应的阈值3，因此该发券人员的第一个发券指标符合发券规则中与该发券指标对应的阈值。

将第二个发券指标进行比对，发券人员信息的近7个工作日大厅搜索次数8小于第二个发券指标对应的阈值10，因此该发券人员的第二个发券指标不符合发券规则中与该发券指标对应的阈值。

将第三个发券指标进行比对，发券人员信息的信用分700大于第三个发券指标对应的阈值600，因此该发券人员的第三个发券指标符合发券规则中与该发券指标对应的阈值。

综上所述，该发券人员信息对应的符合数量为2。

具体地，根据发券人员信息对应的符合数量，确定目标发券人员。

具体地，判断发券人员信息对应的符合数量是否大于预设数量；若发券人员信息对应的符合数量大于预设数量，则将发券人员信息对应的发券人员确定为目标发券人员。

可选地，用户还可以在电子券发放界面输入发放人数，判断目标发券人员的数量是否大于发放人数，若目标发券人员的数量大于发放人数，则将目标发券人员中符合数量在前的与发放人数相同数量的目标发券人员确定为最终的目标发券人员。

本申请实施例提供了一种电子券的处理方法，该方法应用于电子券服务器，该电子券的处理方法包括：获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。本申请通过用户在电子券创建界面输入的至少一个电子券的发券规则，为用户确定目标发券人员，不需要重新开发数仓，减小时间成本。

参照图2所示，为本申请实施例提供的另一种电子券的处理方法的流程示意图，步骤S204参照图1中步骤S103，该电子券的处理方法包括：

S201、获取用户在电子券创建界面输入的至少一个电子券的发券规则。

在本申请实施方式中，用户在电子券创建界面输入至少一个电子券的发券规则，还会输入电子券的优惠内容。电子券的发券规则中包括至少一个发券指标及对应的阈值。发券指标可以为“近7个工作日登陆天数”、“近7个工作日大厅搜索次数”、“信用分”等。“近7个工作日登陆天数”对应的阈值可以为大于等于3等，“近7个工作日大厅搜索次数”对应的阈值可以为大于10，“信用分”对应的阈值可以为大于600等等，发券指标和阈值不做具体限定，可以根据实际情况而定。

S202、获取用户在电子券发放界面输入的发放周期。

在本申请实施方式中，发放周期用于指定发放电子券的周期。例如周期为1天，那么就每隔1天向目标发券人员发送一次优惠券。

S203、按照发放周期将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息。

在本申请实施方式中，人员信息数据库中对应存储有发券人员标识、至少一个发券指标及对应的数值。发券人员指的是该用户店铺中的所有客户。

其中，发券人员信息中包括至少一个发券指标及对应的数值。

S204、针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。

具体地，针对每一个发券人员信息，统计发券人员信息中发券指标的数值符合发券规则中与发券指标对应的阈值的发券指标的个数，得到发券人员信息对应的符合数量。根据发券人员信息对应的符合数量，确定目标发券人员。判断发券人员信息对应的符合数量是否大于预设数量；若发券人员信息对应的符合数量大于预设数量，则将发券人员信息对应的发券人员确定为目标发券人员。

本申请实施例提供了另一种电子券的处理方法，该方法包括：获取用户在电子券创建界面输入的至少一个电子券的发券规则；获取用户在电子券发放界面输入的发放周期；按照发放周期将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。通过该方法能够指定发放电子券的发放周期，不需要用户经常创建电子券以及电子券对应的发券规则。

参照图3所示，为本申请实施例提供的另一种电子券的处理方法的流程示意图，步骤S301至步骤S303参照步骤S101至S103，该电子券的处理方法包括：

S301、获取用户在电子券创建界面输入的至少一个电子券的发券规则。

S302、将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息。

S303、针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的发券人员信息。

S304、将符合电子券的发券规则的发券人员信息确定为初始发券人员。

S305、从电子券数据库中获取与初始发券人员对应的已拥有电子券。

在本申请实施方式中，电子券数据库中对应存储有已拥有电子券、发券人员标识。

在本申请实施方式中，已拥有电子券指初始发券人员当前已经拥有的电子券。

S306、若初始发券人员对应的拥有电子券中，不包含电子券的初始发券人员确定为目标发券人员。

在本申请实施方式中，若初始发券人员对应的拥有电子券中不包含电子券，则说明需要给该初始发券人员发放该电子券。

进一步地，若初始发券人员对应的拥有电子券中包含电子券，则说明该初始发券人员已经发放了该电子券，则本次不再给该初始发券人员发券。

本申请提供了另一种电子券的处理方法，能够防止重复将电子券发放给同一个发券人员，造成损失。

参照图4所示，为本申请实施例提供的一种电子券服务器的示意图，该电子券服务器包括：

获取模块401，用于获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；

发送模块402，用于将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；

确定模块403，用于针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。

在一种可能的实施方式中，电子券服务器还包括：

获取模块401，还用于获取用户在电子券发放界面输入的发放周期；

发送模块402，还用于按照发放周期将电子券发送给目标发券人员。

在一种可能的实施方式中，确定模块403，具体用于：将符合电子券的发券规则的发券人员信息确定为初始发券人员；从电子券数据库中获取与初始发券人员对应的已拥有电子券；若初始发券人员对应的拥有电子券中，不包含电子券的初始发券人员确定为目标发券人员。

在一种可能的实施方式中，电子券的发券规则包括至少一个发券指标及对应的阈值；发券人员信息中包括至少一个发券指标及对应的数值；确定模块403，具体用于针对每一个发券人员信息，统计发券人员信息中发券指标的数值符合发券规则中与发券指标对应的阈值的发券指标的个数，得到发券人员信息对应的符合数量；根据发券人员信息对应的符合数量，确定目标发券人员。

在一种可能的实施方式中，确定模块403，具体用于判断发券人员信息对应的符合数量是否大于预设数量；若发券人员信息对应的符合数量大于预设数量，则将发券人员信息对应的发券人员确定为目标发券人员。

本申请实施例提供了一种电子券服务器，该电子券服务器包括：获取模块401，用于获取用户在电子券创建界面输入的至少一个电子券的发券规则；每个用户对应唯一的用户标识；发送模块402，用于将用户标识发送给人员信息数据库，以使人员信息数据库查询与用户标识对应的发券人员信息；确定模块403，用于针对每一个电子券，从人员信息数据库发送的发券人员信息中确定符合电子券的发券规则的目标发券人员；并将电子券发送给目标发券人员。本申请通过用户在电子券创建界面输入的至少一个电子券的发券规则，为用户确定目标发券人员，不需要重新开发数仓，减小时间成本。

如图5所示，本申请实施例提供的一种电子设备500，包括：处理器501、存储器502和总线，存储器502存储有处理器501可执行的机器可读指令，当电子设备运行时，处理器501与存储器502之间通过总线通信，处理器501执行所述机器可读指令，以执行如上述电子券的处理方法的步骤。

具体地，上述存储器502和处理器501能够为通用的存储器和处理器，这里不做具体限定，当处理器501运行存储器502存储的计算机程序时，能够执行上述电子券的处理方法。

对应于上述电子券的处理方法，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行上述电子券的处理方法的步骤。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考方法实施例中的对应过程，本申请中不再赘述。在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述信息处理方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。