本公开涉及互联网技术领域，更具体地，涉及一种优惠券发放方法和装置以及计算机系统和介质。
背景技术：
随着电子商务的不断发展，电子商务在用户的日常生活中占据越来越重要的地位，例如，京东世纪贸易(简称京东)的用户规模和成交总额(crossmerchandisevolume，简称gmv)不断扩大，基于用户个性化需求的智能营销目前已经应用到京东消费的各个场景。优惠券作为智能营销的一种有效手段，在激活和提升用户潜在下单需求、给平台引进新用户等方面扮演越来越重要的角色，因此，如何利用优惠券以最小的促销成本来获得最优的gmv与独立访客(uniquevisitor，简称uv)指标成为亟待解决的问题。
为了解决上述问题，现有技术中的优惠券发放方法主要有两种，第一种方法，由运营人员人工筛选候选人群，然后将优惠券发送到被筛选到人群的用户账户中；第二种方法，在促销活动页面设置领券区域，由用户自行领取。
在实现本公开构思的过程中，发明人发现现有技术中的优惠券发放方法存在以下问题：对于上述第一种方法，由于运营人员只能根据简单的条件进行人群筛选，因此，优惠券不能精准发到需要优惠券的人群手中，不能使优惠券的投资回报率(returnoninvestment，简称roi)最大化，进而无法有效提升gmv；对于第二种方法，在促销活动页发送优惠券，由于消费者(用户)的信息不对称性以及时间机会成本的不同，会造成很多有很强购买意向的消费者由于不了解进入促销活动页的领券途径和/或领卷领用时间等，从而使得第二种优惠券发放方法无法将优惠券精准发到需要优惠券的人群手中，从而无法达到最优效果，进而无法提升gmv。
技术实现要素：
有鉴于此，本公开提供了一种能够将优惠券精准发到需要优惠券的人群手中以提升gvm指标和uv指标的优惠券发放方法和装置以及计算机系统和介质。
本公开的一个方面提供了一种优惠券发放方法，包括：首先，获取与用户购买商品相关的用户操作数据，然后，根据所述用户操作数据确定所述用户的适用优惠券，接着，基于所述用户的用户属性对所述适用优惠券进行过滤，得到个性化优惠券，由于优惠券的数量和金额总数等有限，因此，基于所述用户的用户属性对所述适用优惠券进行过滤可以至少节省部分优惠券，得到最适合每个用户的个性化的优惠券推荐方式，并且可以将节省的优惠券发放给更需要使用优惠券的用户，这样可以有效地将优惠券精准发到最需要的人群手中，以提升网购平台的gvm指标和uv指标。
根据本公开的实施例，所述用户操作数据包括以下任意一种或多种：搜索、点击、浏览、加入购物车或购买。通过这些用户操作数据可以快速简洁地统计出用户所需的优惠券。
根据本公开的实施例，所述用户操作数据包括实时的用户操作数据和历史的用户操作数据，通常采用历史的用户操作数据处理得到的优惠券信息更加准确，但是，实时的用户操作数据能更好的应对用户的倾向发生改变的情形，因此，结合用户长期的行为以及实时的点击下单信息，可以更加精准实时的对用户进行优惠券推送，相应地，所述根据所述用户操作数据确定所述用户的适用优惠券包括根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券。
根据本公开的实施例，所述用户属性包括购买力范围和/或优惠券敏感度。由于用户属性多种多样，如年龄、性别、收入范围、颜色倾向和爱好等很多，本公开在实施过程中经过大量统计和分析工作找到了与优惠券和gmv的关联最明显的两个指标：购买力范围和优惠券敏感度，通过这两个指标能有效表征用户使用推荐的优惠券进行购物的倾向。
根据本公开的实施例，所述用户属性可以通过以下方式确定，对于购买力范围，可以首先获取第一指定时长阈值内的历史的用户操作数据，作为第一用户操作数据，然后根据所述第一用户操作数据和第一模型确定用户的购买力范围。而对于优惠券敏感度，可以首先获取第二指定时长阈值内的历史的用户操作数据，作为第二用户操作数据，然后根据所述第二用户操作数据和第二模型确定用户的优惠券敏感度。
根据本公开的实施例，所述用户属性还可以通过以下方式确定，首先，根据实时的用户操作数据和历史的用户操作数据确定用户欲购商品所属的品类，然后，基于用户欲购商品所属的品类确定用户的购买力范围和对优惠券敏感度。其中，对于购买力范围，可以首先获取第三指定时长阈值内的在所述品类下的所述历史的用户操作数据，作为第三用户操作数据，然后根据所述第三用户操作数据和第三模型确定用户的购买力范围，而对于优惠券敏感度，可以首先获取第四指定时长阈值内的在所述品类下的历史的用户操作数据，作为第四用户操作数据，然后，根据所述第四用户操作数据和第四模型确定用户的优惠券敏感度。
根据本公开的实施例，所述根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券可以包括如下操作，首先，根据实时的用户操作数据确定所述用户的第一适用优惠券，然后，根据历史的用户操作数据确定所述用户的第二适用优惠券，接着，根据所述用户的第一适用优惠券以及所述用户的第二适用优惠券得到所述用户的适用优惠券。这样就可以实现结合用户长期的行为以及实时的点击下单信息，更加精准实时的对用户进行优惠券推送。
根据本公开的实施例，所述根据实时的用户操作数据确定所述用户的第一适用优惠券可以包括如下操作，首先，通过页面埋点记录用户操作数据，然后，将脱密后的用户操作数据发送给kafka集群，接着，根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券。这样可以实现采用在线的第一推荐模型得到适用于用户的优惠券。
根据本公开的实施例，所述根据所述kafka集群中的用户的操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券可以包括如下操作，首先，根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第二推荐模型得到所述用户的欲购商品所属的品类，然后，根据所述欲购商品所属的品类确定所述用户的第一适用优惠券。
根据本公开的实施例，所述方法还可以进一步包括如下操作，在得到所述用户的欲购商品所属的品类之后，基于用户的购买力范围和所述欲购商品所属的品类确定欲购商品的品牌，相应地，所述根据所述欲购商品所属的品类确定所述用户的第一适用优惠券包括根据所述欲购商品所属的品类、所述欲购商品的品牌确定所述用户的第一适用优惠券。这样可以进一步细化推荐的优惠券的种类，如用户有购买具体品牌的衣服的倾向时，可以给用户推荐该品牌的衣服的优惠券，而不是推荐服装品类的优惠券，这样可以有效的推送更多更加细化的优惠券，至少部分解决优惠券只有推送的通用优惠券或某些品类的优惠券的反响效果好，更加细分的优惠券的反响效果不佳的情况。
根据本公开的实施例，所述根据历史的用户操作数据确定所述用户的第二适用优惠券可以包括如下操作，首先，对页面埋点日志进行数据仓库技术(extract-transform-load，简称etl)解析，得到解析结果，然后，将脱密的解析结果存储在离线数据表中，接着，根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券。这样可以实现通过hadoop计算对离线数据表提取特征以训练离线的推荐模型，以利用训练好的离线推荐模型得到适用于用户的优惠券。
根据本公开的实施例，所述根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券可以包括如下操作，首先，根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第四推荐模型得到所述用户的欲购商品所属的品类，然后，根据所述欲购商品所属的品类确定所述用户的第二适用优惠券。
根据本公开的实施例，所述方法还可以包括如下操作，在得到所述用户的欲购商品所属的品类之后，基于用户的购买力范围和所述欲购商品所属的品类确定欲购商品的品牌，相应地，所述根据所述欲购商品所属的品类确定所述用户的第二适用优惠券包括根据所述欲购商品所属的品类、所述欲购商品的品牌确定所述用户的第二适用优惠券。
本公开的另一个方面提供了一种优惠券发放装置，包括第一获取模块、第二获取模块、过滤模块和发送模块，其中，所述第一获取模块用于获取与用户购买商品相关的用户操作数据，所述第二获取模块用于根据所述用户操作数据确定所述用户的适用优惠券，所述过滤模块用于基于所述用户的用户属性对所述适用优惠券进行过滤，得到个性化优惠券，所述发送模块用于发送所述个性化优惠券。
根据本公开的实施例，所述用户操作数据可以包括实时的用户操作数据和历史的用户操作数据，相应地，所述第二获取模块具体用于根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券。
根据本公开的实施例，所述用户属性可以包括购买力范围和/或优惠券敏感度。
根据本公开的实施例，所述过滤模块可以包括第一获取单元和第一确定单元，其中，所述第一获取单元用于获取第一指定时长阈值内的历史的用户操作数据，作为第一用户操作数据，所述第一确定单元用于根据所述第一用户操作数据和第一模型确定用户的购买力范围。和/或所述过滤模块可以包括第二获取单元和第二确定单元，其中，所述第二获取单元用于获取第二指定时长阈值内的历史的用户操作数据，作为第二用户操作数据，第二确定单元用于根据所述第二用户操作数据和第二模型确定用户的优惠券敏感度。
根据本公开的实施例，所述第二获取模块可以包括第三确定单元、第四确定单元和第三获取单元，其中，所述第三确定单元用于根据实时的用户操作数据确定所述用户的第一适用优惠券，所述第四确定单元用于根据历史的用户操作数据确定所述用户的第二适用优惠券，所述第三获取单元用于根据所述用户的第一适用优惠券以及所述用户的第二适用优惠券得到所述用户的适用优惠券。
根据本公开的实施例，所述第三确定单元可以包括记录子单元、第一发送子单元和第一获取子单元，所述记录子单元用于通过页面埋点记录用户操作数据，所述第一发送子单元用于将脱密后的用户操作数据发送给kafka集群，所述第一获取子单元用于根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券。
根据本公开的实施例，所述第四确定单元可以包括解析子单元、存储子单元和第二获取子单元，其中，所述解析子单元用于对页面埋点日志进行etl解析，得到解析结果，所述存储子单元用于将脱密的解析结果存储在离线数据表中，所述第二获取子单元用于根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券。
本公开的另一个方面提供了一种计算机系统，包括一个或多个处理器，以及存储装置，其中，所述存储装置用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现如上所述的方法。
本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。
本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。
根据本公开的实施例，可以至少部分地解决现有的优惠券发放方法无法精准地将优惠券发放给需要该优惠券的用户的问题，并因此可以提升gvm指标和uv指标的技术效果。
根据本公开的实施例，用户操作数据可以包含实时的用户操作数据和历史的用户操作数据，隐藏可以实现结合用户长期的行为以及实时的点击下单行为，更加精准实时地确定用户所需要的优惠券。
根据本公开的实施例，可以根据用户的历史行为，准确实时的计算用户对商品价位购买力偏好、使用优惠券敏感度偏好，为用户推送最适合自己的优惠券，做到优惠券的千人千面，有效提升gmv。
根据本公开的实施例，个性化的确定每个用户所需的优惠券，如利用storm分布式计算框架进行实时计算，对于历史离线数据，基于hadoop进行计算，这样能满足业务方离线和实时的多个应用场景下的需求，并且会提高优惠券发放精准度。
根据本公开的实施例，利用脱密后的用户操作数据确定推荐的优惠券，有助于保护用户隐私。
附图说明
通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：
图1示意性示出了根据本公开实施例的可以应用优惠券发放方法和装置以及计算机系统和介质的示例性系统架构；
图2示意性示出了根据本公开实施例的优惠券发放方法的流程图；
图3a示意性示出了根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券的流程图；
图3b示意性示出了根据本公开实施例的确定适用优惠券的逻辑图；
图3c示意性示出了根据本公开实施例的根据实时的用户操作数据确定所述用户的第一适用优惠券的流程图；
图3d示意性示出了根据本公开实施例的根据历史的用户操作数据确定所述用户的第二适用优惠券；
图3e示意性示出了根据本公开实施例的适用优惠券的示意图；
图4示意性示出了根据本公开实施例的优惠券发放装置的框图；以及
图5示意性示出了根据本公开实施例的适于优惠券发放方法的计算机系统的方框图。
具体实施方式
以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
在使用类似于“a、b和c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b和c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。在使用类似于“a、b或c等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有a、b或c中至少一个的系统”应包括但不限于单独具有a、单独具有b、单独具有c、具有a和b、具有a和c、具有b和c、和/或具有a、b、c的系统等)。本领域技术人员还应理解，实质上任意表示两个或更多可选项目的转折连词和/或短语，无论是在说明书、权利要求书还是附图中，都应被理解为给出了包括这些项目之一、这些项目任一方、或两个项目的可能性。例如，短语“a或b”应当被理解为包括“a”或“b”、或“a和b”的可能性。
本公开的实施例提供了一种优惠券发放方法和装置以及计算机系统和介质。该方法包括优惠券确定过程、优惠券过滤过程和优惠券发放过程。在优惠券确定过程中，首先，获取与用户购买商品相关的用户操作数据，然后，根据所述用户操作数据确定所述用户的适用优惠券，这样就可以初步确定用户可能需要哪些优惠券。在完成优惠券确定过程之后，进入优惠券过滤过程，基于所述用户的用户属性对所述适用优惠券进行过滤，得到个性化优惠券，通过过滤可以有效缩小该用户可能使用的优惠券的范围，至少部分避免将用户不需要的优惠券发放给用户，即可以有效提升优惠券发放的精准度，有助于提升gmv。
图1示意性示出了根据本公开实施例的可以应用优惠券发放方法和装置以及计算机系统和介质的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。
如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
终端设备101、102、103可以是具有显示屏并且支持网页浏览、网上购物的各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器105可以是提供各种服务的服务器，例如对用户利用终端设备101、102、103所浏览的网站提供支持的后台管理服务器(仅为示例)。例如，对用户利用终端设备101、102、103所产生的用户操作数据进行采集、对采集的用户操作数据进行分析、过滤，以获取个性化优惠券，此外，还可以进行优惠券发放等。后台管理服务器还可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的推荐信息，如优惠券、网页、信息、或数据等)反馈给终端设备。
需要说明的是，本公开实施例所提供的优惠券发放方法一般可以由服务器105执行。相应地，本公开实施例所提供的优惠券发放装置一般可以设置于服务器105中。本公开实施例所提供的优惠券发放方法也可以由不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的优惠券发放装置也可以设置于不同于服务器105且能够与终端设备101、102、103和/或服务器105通信的服务器或服务器集群中。
应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
图2示意性示出了根据本公开实施例的优惠券发放方法的流程图。
如图2所示，该方法可以包括操作s201～操作s204。
首先，在操作s201，获取与用户购买商品相关的用户操作数据。
在本实施例中，可以由为电子商务平台提供服务的服务器来收集与用户购买商品相关的用户操作数据，也可以是由其它服务器根据电子商务平台的服务器发送的数据，来收集与用户购买商品相关的用户操作数据。具体地，所述用户操作数据包括以下任意一种或多种：搜索、点击、浏览、加入购物车或购买。这些操作数据可以表明用户的一些意向，可以根据这些意向分析用户是否需要某些商品。
考虑到用户点击或搜索某些商品时可能是一时兴起的操作，购买意向并不强烈，因此，需要结合实时的用户操作数据和历史的用户操作数据来判断用户的购买意向。
具体地，所述用户操作数据可以包括实时的用户操作数据和历史的用户操作数据，相应地，所述根据所述用户操作数据确定所述用户的适用优惠券包括根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券。
其中，实时的用户操作数据可以指当前用户的即时操作所产生的数据，也可以是距离当前时间点的一定时间段内用户的操作所产生的数据，例如，1秒、3秒、30秒、1分钟、5分钟、10分钟、30分钟、1小时、6小时、12小时或24小时内用户操作所产生的数据，也可以是距离当前时间点最近的数次用户操作，如1次、3次、5次、10次、50次、100次等。
然后，在操作s202，根据所述用户操作数据确定所述用户的适用优惠券。
在本实施例中，可以采用在线推荐模型和/或离线推荐模型来确定所述用户的适用优惠券。该在线推荐模型可以采用storm分布式计算框架，该离线推荐模型可以为神经网络、回归模型等。以离线推荐模型为例进行说明，该离线推荐模型可以是基于hadoop的分布式计算架构，时效性为t 1天，其中，t为预设周期。该离线推荐模型的训练过程可以如下所示：将用户操作数据中的搜索、点击、浏览或者加入购物车中的一种或多种作为离线推荐模型的输入数据，将用户操作数据中的购买作为离线推荐模型的输出数据，将上述输入数据和输出数据作为离线推荐模型的训练数据，然后，将上述训练数据输入离线推荐模型进行模型训练，得到模型参数，例如，得到模型的权重和偏置的值使得离线推荐模型的输出接近正确的输出。这样，就可以利用训练好的离线推荐模型确定所述用户的适用优惠券。
需要说明的是，当所述用户操作数据包括实时的用户操作数据和历史的用户操作数据时，所述根据所述用户操作数据确定所述用户的适用优惠券可以包括根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券。也就是说，可以分别采用离线推荐模型和在线推荐模型分别对历史的用户操作数据和实时的用户操作数据进行处理，得到两种优惠券，然后可以基于实际使用效果以预定的方式对两种优惠券进行处理得到要推荐的优惠券，该预定的方式包括但不限于以下任意一种或多种：取交集、取并集、按预设的权重分别在两种优惠券中取排序靠前的指定个数的优惠券等。这种确定优惠券的方式既能根据历史的用户操作数据提升推荐的准确度，还可以根据实时的用户操作数据及时的反映出用户的当前需求，有助于提升推荐的优惠券被使用的可能性。
在一个具体实施例中，结合用户离线一段时间和实时的数条用户操作数据，如用户操作记录，预测出该用户对某品类的购买意图。其中离线推荐模型可以是利用用户历史三个月的滑动窗口数据，基于hadoop分布式计算框架进行计算。在线推荐模型可以是利用用户在当前时刻的最近若干条实时数据流，基于storm计算框架进行计算。
此外，为了进一步确定适用于用户的更加细化的优惠券，还可以结合用户对某品类的购买意图，基于品牌维度计算用户对某品牌的购买意图。这样便于给用户推荐更加有针对性的优惠券，针对性越强的优惠券的优惠力度往往越大，这样有助于为用户节省资金。此外，适用范围更广的优惠券可以推荐给其他用户使用，有助于更合理的分配优惠券资源。
接着，在操作s203，基于所述用户的用户属性对所述适用优惠券进行过滤，得到个性化优惠券。
在本实施例中，所述用户属性可以包括但不限于以下任意一种或多种：用户性别、用户年龄段、用户收入水平、用户的地理位置、用户的网购年限等，可以根据这些用户属性对上一操作中确定的优惠券进行过滤，来获取适用于用户的个性化优惠券，例如，不给老年男性发放化妆品类的优惠券，不给处于热带地区的用户发放御寒服饰品类的优惠券等，在此不再一一列举。
具体地，所述用户属性可以包括购买力范围和/或优惠券敏感度。本公开的技术方案在被实施的过程中，为了优化用户属性并提升发放的优惠券的准确度，对上述用户属性进行进一步的细分和重组，并根据细分和重组后的用户属性和推荐的优惠券被使用的相关度进行统计分析，发现购买力范围和/或优惠券敏感度与推荐的优惠券被使用呈现强相关性。例如，虽然用户收入水平与推荐的优惠券被使用的概率相关性较强，但是，仍然有部分高收入水平的用户很少使用优惠券，例如，该用户较少网购或不习惯使用优惠券，这就造成这部分优惠券被浪费，经过细分和重组后，得到了两个强相关的指标：购买力范围和优惠券敏感度，当这两个指标满足一定条件时，被发放的优惠券被使用的概率很低。例如，某个用户在鞋子品类的购买力范围在800元以内，如果推荐的优惠券对应的鞋子品类的商品的价格超过1000元，则用户使用该优惠券的概率较低，会造成优惠券资源的浪费，因此可以不发放该优惠券。又例如，根据历史的用户操作数据可以得知用户对某些品类的商品的优惠券不敏感(很少使用该品类的商品的优惠券)，虽然不便于得知具体原因，但是，可以根据该信息得知给用户推荐该品类的商品的优惠券时，优惠券被使用的概率较低，因此可以不发放该优惠券以免优惠券资源被浪费。
在一个具体实施例中，所述用户属性通过以下方式确定：对于购买力范围，首先，获取第一指定时长阈值内的历史的用户操作数据，作为第一用户操作数据，然后，根据所述第一用户操作数据和第一模型确定用户的购买力范围。对于优惠券敏感度，首先，获取第二指定时长阈值内的历史的用户操作数据，作为第二用户操作数据，然后，根据所述第二用户操作数据和第二模型确定用户的优惠券敏感度。其中，第一指定时长阈值和第二指定时长阈值可以相同或不同。
在另一个具体实施例中，所述用户属性可以具体到具体的类别下，例如，所述用户属性可以通过以下方式确定：首先根据实时的用户操作数据和历史的用户操作数据确定用户欲购商品所属的品类；然后分别确定用户欲购商品所属的品类下的购买力范围和/或优惠券敏感度，例如，有的用户对旅游类商品比较感兴趣，而对餐饮类商品不感兴趣，虽然用户的收入水平不高，但是其对旅游类商品具有较高的购买力范围。
其中，对于购买力范围，可以首先获取第三指定时长阈值内的在所述品类下的所述历史的用户操作数据，作为第三用户操作数据，然后，根据所述第三用户操作数据和第三模型确定用户的购买力范围，例如，基于用户历史一个月的用户操作数据，预测出该用户相应三级品类的商品的购买力范围，从而决定该品类的商品的优惠券发放门槛，避免发放超过用户购买力范围的优惠券。
对于优惠券敏感度，可以首先获取第四指定时长阈值内的在所述品类下的历史的用户操作数据，作为第四用户操作数据，然后，根据所述第四用户操作数据和第四模型确定用户的优惠券敏感度。例如，可以基于用户历史一年的优惠券使用数据，通过分类将该用户划分到相应的用户活跃人群。如果在操作s203中确定的优惠券所属的品类与用户被划分到的人群敏感的优惠券所属的品类不同时，可以不给该用户发放在操作s203中确定的优惠券。
需要说明的是，第一指定时长阈值、第二指定时长阈值、第三指定时长阈值和第四指定时长阈值可以相同或不同，具体根据使用效果而定。
然后，在操作s204，发送所述个性化优惠券。
具体地，可以提供接口以供业务方调用，例如，可以通过优惠券发放平台将优惠券发放给用户，优惠券发放平台可以通过接口调用个性化优惠券以发放给对应的用户。需要说明的是，优惠券发放平台和优惠券推荐模型所处的服务器可以是同一个服务器，也可以不是同一个服务器，只要能通过接口调用相应的数据即可。
图3a示意性示出了根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券的流程图。
在图3a中示出了确定所述用户的适用优惠券的流程图，具体可以包括操作s301～操作s303。
在操作s301中，根据实时的用户操作数据确定所述用户的第一适用优惠券。
在本实施例中，可以基于在线的优惠券推荐模型来确定所述用户的第一适用优惠券。例如，通过基于storm分布式计算框架构建的模型对实时的用户操作数据的数据流进行处理，得到所述用户的第一适用优惠券。这样可以满足用户的实时性需求。
在操作s302中，根据历史的用户操作数据确定所述用户的第二适用优惠券
在本实施例中，可以基于离线的优惠券推荐模型来确定所述用户的第二适用优惠券。例如，通过基于hadoop分布式计算框架构建的模型对历史的用户操作数据的数据流进行处理，得到所述用户的第二适用优惠券。这样可以提升确定的优惠券的准确度。
在操作s303中，根据所述用户的第一适用优惠券以及所述用户的第二适用优惠券得到所述用户的适用优惠券。
在本实施例中，可以对第一适用优惠券和第二适用优惠券取交集、并集或者分别取排名靠前的第一适用优惠券和第二适用优惠券作为所述用户的适用优惠券，此外，还可以对第一适用优惠券和第二适用优惠券分别设置不同的权重，根据权重来选取一定数量的适用优惠券，在此不再一一列举。由于采用了基于离线的优惠券推荐模型和基于在线的优惠券推荐模型，结合用户长期的行为以及实时的点击下单信息，更加精准实时地确定用户适用的优惠券。
图3b示意性示出了根据本公开实施例的确定适用优惠券的逻辑图。以下结合图3c和图3d对图3b进行示例性说明。
图3c示意性示出了根据本公开实施例的根据实时的用户操作数据确定所述用户的第一适用优惠券的流程图。
如图3c所示，确定所述用户的第一适用优惠券的流程图可以包括操作s3011～操作s3013。
在操作s3011中，通过页面埋点记录用户操作数据。
该页面埋点主要用于收集用户的行为数据，具体可以为如：googleanalytics、百度统计、友盟 等，可以通过在页面上接入jssdk代码来实现。该用户操作数据包含内部id、操作活动(包含搜索、点击、浏览、加入购物车、购买等)。
在操作s3012中，将脱密后的用户操作数据发送给kafka集群。
其中，此处需要对用户操作数据进行脱密处理，避免用户隐私泄露，具体地，对数据进行脱敏处理使得数据中不含有用户隐私信息，然后实时发送这些信息到kafka集群。kafka是由apache开发的一个开源流处理平台，具有统一、高吞吐、低延迟的属性，是一个分布式日志架构的大规模发布订阅消息队列，可以和storm集成。此处应用它，是接收生产者发送过来的用户实时操作记录。
在操作s3013中，根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券。本公开可以利用storm分布式计算框架对kafka集群中的流式数据进行批量、分布式处理。
在一个具体实施例中，所述根据所述kafka集群中的用户的操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券可以包括如下操作，首先，根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第二推荐模型得到所述用户的欲购商品所属的品类，然后，根据所述欲购商品所属的品类确定所述用户的第一适用优惠券。
在另一个具体实施例中，该方法还可以进一步包括如下操作：在得到所述用户的欲购商品所属的品类之后，基于用户的购买力范围和所述欲购商品所属的品类确定欲购商品的品牌。相应地，所述根据所述欲购商品所属的品类确定所述用户的第一适用优惠券可以包括根据所述欲购商品所属的品类、所述欲购商品的品牌确定所述用户的第一适用优惠券。这样可以基于所述欲购商品所属的品类、所述欲购商品的品牌给用户推荐更加有针对性的优惠券，实现精细化推荐，有助于提升用户体验度，且由于可以推荐针对具体品牌的优惠券，这样可以将该品牌所属品类的优惠券推荐给其他用户，有助于节省优惠券资源。
图3d示意性示出了根据本公开实施例的根据历史的用户操作数据确定所述用户的第二适用优惠券。
如图3d所示，确定所述用户的第一适用优惠券的流程图可以包括操作s3021～操作s3023。
在操作s3021中，对页面埋点日志进行etl解析，得到解析结果。
将用户的页面埋点日志，按照预设周期进行etl解析，例如，按照天级进行etl解析。
在操作s3022中，将脱密的解析结果存储在离线数据表中。
将解析结果存储到数据库中，例如，京东数据仓库，用户的不同行为分别存储到相应集市的离线hive表中。然后可以进行hadoop分布式文件系统(hdfs)存储，该hdfs可以用来存储海量的时效性要求不高的离线数据。将etl解析后的离线数据表，用hadoop的分布式计算框架进行处理。
在操作s3023中，根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券。
具体地，所述第三推荐模型可以是基于hadoop的分布式计算框架的模型，时效性可以为指定的天数。对离线数据表的用户行为(如搜索、点击、浏览、加入购物车或购买)进行特征提取，以便根据特征确定所述用户的第二适用优惠券。该第三推荐模型可以通过机器学习的方式进行模型训练，例如，将搜索、点击、浏览、加入购物车等数据，以及对应的购买数据分别输入第三推荐模型的输入和输出，通过调整模型参数使得第三推荐模型的输出趋近于正确输出(对应购买数据)。
在一个具体实施例中，所述根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券可以包括如下操作，首先，根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第四推荐模型得到所述用户的欲购商品所属的品类，然后，根据所述欲购商品所属的品类确定所述用户的第二适用优惠券。
在另一个具体实施例中，该方法还可以进一步包括如下操作：在得到所述用户的欲购商品所属的品类之后，基于用户的购买力范围和所述欲购商品所属的品类确定欲购商品的品牌。相应地，所述根据所述欲购商品所属的品类确定所述用户的第二适用优惠券包括根据所述欲购商品所属的品类、所述欲购商品的品牌确定所述用户的第二适用优惠券。这样可以基于所述欲购商品所属的品类、所述欲购商品的品牌给用户推荐更加有针对性的第二适用优惠券，实现精细化推荐，有助于提升用户体验度，且由于可以推荐针对具体品牌的优惠券，这样可以将该品牌所属品类的优惠券推荐给其他没有对具体品牌具有倾向性的用户，有助于节省优惠券资源。
图3e示意性示出了根据本公开实施例的适用优惠券的示意图。
如图3e所示，第一推荐模型或者第二推荐模型确定了鞋子优惠券和烟草优惠券两个适用优惠券，相应地，第三推荐模型或者第四推荐模型确定了果鲜优惠券、钢琴优惠券和旅游优惠券三个适用优惠券，可以将这五个优惠券作为所述用户的适用优惠券，所述用户的适用优惠券为综合考虑了实时的用户操作信息和历史的用户操作信息之后确定的适用优惠券，能基本覆盖用户对优惠券的需求，然后，基于所述用户的用户属性(如用户的购买力范围和优惠券敏感度)对所述适用优惠券进行过滤，由于历史的用户操作信息表明该用户没有在电子商城中购买价格超过20000元的商品，虽然该用户曾查看过具体型号的钢琴的相关信息，但是可能是做基本信息了解等，使用优惠券购买的可能性不高，因此可以过滤相应的优惠券。此外，该用户虽然在网上购买过烟草，但是该用户的历史的用户操作数据表明该用户从未使用过烟草品类的优惠券购买烟草，这表明该用户对烟草品类的优惠券不敏感，该用户利用烟草品类的优惠券购买烟草的概率不高，因此可以过滤相应的优惠券。在经过过滤后，可以得到鞋子优惠券、果鲜优惠券和旅游优惠券三个个性化优惠券，此时，可以通过优惠券发放平台将这三个个性化优惠券发放给对应的用户，这三个个性化优惠券被用户使用的概率较高，能有助于提升gmv和uv，且能降低优惠券资源的浪费。
图4示意性示出了根据本公开实施例的优惠券发放装置的框图。
如图4所示，装置400可以包括第一获取模块410、第二获取模块420、过滤模块430和发送模块440，其中，第一获取模块410、第二获取模块420、过滤模块430和发送模块440的实现方法可以参考对应的方法部分的详细描述，在此不再赘述。
其中，第一获取模块410用于获取与用户购买商品相关的用户操作数据。
第二获取模块420用于根据所述用户操作数据确定所述用户的适用优惠券。
过滤模块430用于基于所述用户的用户属性对所述适用优惠券进行过滤，得到个性化优惠券。
发送模块440用于发送所述个性化优惠券。
在一个实施例中，所述用户操作数据包括实时的用户操作数据和历史的用户操作数据。相应地，所述第二获取模块420具体用于根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券。
其中，所述用户属性可以包括购买力范围和/或优惠券敏感度。
在另一个实施例中，所述过滤模块430可以包括第一获取单元和第一确定单元。
其中，第一获取单元用于获取第一指定时长阈值内的历史的用户操作数据，作为第一用户操作数据。
第一确定单元用于根据所述第一用户操作数据和第一模型确定用户的购买力范围。
此外，所述过滤模块430也可以包括第二获取单元和第二确定单元。
其中，第二获取单元用于获取第二指定时长阈值内的历史的用户操作数据，作为第二用户操作数据。
第二确定单元用于根据所述第二用户操作数据和第二模型确定用户的优惠券敏感度。
为了提升获取的优惠券对用户的适用性，所述第二获取模块420可以包括第三确定单元、第四确定单元和第三获取单元。
其中，第三确定单元用于根据实时的用户操作数据确定所述用户的第一适用优惠券。
第四确定单元用于根据历史的用户操作数据确定所述用户的第二适用优惠券。
第三获取单元用于根据所述用户的第一适用优惠券以及所述用户的第二适用优惠券得到所述用户的适用优惠券。
在一个具体实施例中，所述第三确定单元可以包括：记录子单元、第一发送子单元和第一获取子单元。
其中，所述记录子单元用于通过页面埋点记录用户操作数据。
所述第一发送子单元用于将所述脱密后的用户操作数据发送给kafka集群。
所述第一获取子单元用于根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券。
在另一个具体实施例中，所述第四确定单元可以包括：解析子单元、存储子单元和第二获取子单元。
其中，所述解析子单元用于对页面埋点日志进行etl解析，得到解析结果。
所述存储子单元用于将所述脱密的解析结果存储在离线数据表中。
所述第二获取子单元用于根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券。
需要说明的是，所述过滤模块430还可以包括品类确定单元，该品类确定单元可以用于根据实时的用户操作数据和历史的用户操作数据确定用户欲购商品所属的品类。
相应地，所述第一获取单元具体用于获取第三指定时长阈值内的在所述品类下的所述历史的用户操作数据，作为第三用户操作数据。
所述第一确定单元具体用于根据所述第三用户操作数据和第三模型确定用户的购买力范围。
所述第二获取单元具体用于获取第四指定时长阈值内的在所述品类下的历史的用户操作数据，作为第四用户操作数据，以及
所述第二确定单元具体用于根据所述第四用户操作数据和第四模型确定用户的优惠券敏感度。
根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
例如，第一获取模块410、第二获取模块420、过滤模块430和发送模块440中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，第一获取模块410、第二获取模块420、过滤模块430和发送模块440中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(fpga)、可编程逻辑阵列(pla)、片上系统、基板上的系统、封装上的系统、专用集成电路(asic)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，第一获取模块410、第二获取模块420、过滤模块430和发送模块440中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
图5示意性示出了根据本公开实施例的适于实现上文描述的方法的计算机系统的方框图。图5示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图5所示，根据本公开实施例的计算机系统500包括处理器501，其可以根据存储在只读存储器(rom)502中的程序或者从存储部分508加载到随机访问存储器(ram)503中的程序而执行各种适当的动作和处理。处理器501例如可以包括通用微处理器(例如cpu)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(asic))，等等。处理器501还可以包括用于缓存用途的板载存储器。处理器501可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
在ram503中，存储有系统500操作所需的各种程序和数据。处理器501、rom502以及ram503通过总线504彼此相连。处理器501通过执行rom502和/或ram503中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除rom502和ram503以外的一个或多个存储器中。处理器501也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
根据本公开的实施例，系统500还可以包括输入/输出(i/o)接口505，输入/输出(i/o)接口505也连接至总线504。系统500还可以包括连接至i/o接口505的以下部件中的一项或多项：包括键盘、鼠标等的输入部分506；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器610也根据需要连接至i/o接口505。可拆卸介质611，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器610上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。
根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质611被安装。在该计算机程序被处理器501执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的rom502和/或ram503和/或rom502和ram503以外的一个或多个存储器。
附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合，即使这样的组合或结合没有明确记载于本公开中。特别地，在不脱离本公开精神和教导的情况下，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
以上对本公开的实施例进行了描述。但是，这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。
1.一种优惠券发放方法，包括：
获取与用户购买商品相关的用户操作数据；
根据所述用户操作数据确定所述用户的适用优惠券；
基于所述用户的用户属性对所述适用优惠券进行过滤，得到个性化优惠券；以及
发送所述个性化优惠券。
2.根据权利要求1所述的方法，其中，所述用户操作数据包括以下任意一种或多种：搜索、点击、浏览、加入购物车或购买。
3.根据权利要求1所述的方法，其中，所述用户操作数据包括实时的用户操作数据和历史的用户操作数据；
所述根据所述用户操作数据确定所述用户的适用优惠券包括根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券。
4.根据权利要求3所述的方法，其中，所述用户属性包括购买力范围和/或优惠券敏感度。
5.根据权利要求4所述的方法，其中，所述用户属性通过以下方式确定：
对于购买力范围，
获取第一指定时长阈值内的历史的用户操作数据，作为第一用户操作数据，
根据所述第一用户操作数据和第一模型确定用户的购买力范围；
对于优惠券敏感度，
获取第二指定时长阈值内的历史的用户操作数据，作为第二用户操作数据，以及
根据所述第二用户操作数据和第二模型确定用户的优惠券敏感度。
6.根据权利要求4所述的方法，其中，所述用户属性通过以下方式确定：
根据实时的用户操作数据和历史的用户操作数据确定用户欲购商品所属的品类；
对于购买力范围，
获取第三指定时长阈值内的在所述品类下的所述历史的用户操作数据，作为第三用户操作数据，
根据所述第三用户操作数据和第三模型确定用户的购买力范围；
对于优惠券敏感度，
获取第四指定时长阈值内的在所述品类下的历史的用户操作数据，作为第四用户操作数据，以及
根据所述第四用户操作数据和第四模型确定用户的优惠券敏感度。
7.根据权利要求3所述的方法，其中，所述根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券包括：
根据实时的用户操作数据确定所述用户的第一适用优惠券；
根据历史的用户操作数据确定所述用户的第二适用优惠券；以及
根据所述用户的第一适用优惠券以及所述用户的第二适用优惠券得到所述用户的适用优惠券。
8.根据权利要求7所述的方法，其中，所述根据实时的用户操作数据确定所述用户的第一适用优惠券，包括：
通过页面埋点记录用户操作数据；
将脱密后的用户操作数据发送给kafka集群；以及
根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券。
9.根据权利要求8所述的方法，其中，所述根据所述kafka集群中的用户的操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券包括：
根据所述kafka集群中的用户操作数据和基于storm分布式计算框架的第二推荐模型得到所述用户的欲购商品所属的品类；以及
根据所述欲购商品所属的品类确定所述用户的第一适用优惠券。
10.根据权利要求9所述的方法，还包括：
在得到所述用户的欲购商品所属的品类之后，基于用户的购买力范围和所述欲购商品所属的品类确定欲购商品的品牌；以及
所述根据所述欲购商品所属的品类确定所述用户的第一适用优惠券包括根据所述欲购商品所属的品类、所述欲购商品的品牌确定所述用户的第一适用优惠券。
11.根据权利要求7所述的方法，其中，所述根据历史的用户操作数据确定所述用户的第二适用优惠券，包括：
对页面埋点日志进行etl解析，得到解析结果；
将脱密的解析结果存储在离线数据表中；以及
根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券。
12.根据权利要求11所述的方法，其中，所述根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券包括：
根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第四推荐模型得到所述用户的欲购商品所属的品类；以及
根据所述欲购商品所属的品类确定所述用户的第二适用优惠券。
13.根据权利要求12所述的方法，还包括：
在得到所述用户的欲购商品所属的品类之后，基于用户的购买力范围和所述欲购商品所属的品类确定欲购商品的品牌；以及
所述根据所述欲购商品所属的品类确定所述用户的第二适用优惠券包括根据所述欲购商品所属的品类、所述欲购商品的品牌确定所述用户的第二适用优惠券。
14.一种优惠券发放装置，包括：
第一获取模块，用于获取与用户购买商品相关的用户操作数据；
第二获取模块，用于根据所述用户操作数据确定所述用户的适用优惠券；
过滤模块，用于基于所述用户的用户属性对所述适用优惠券进行过滤，得到个性化优惠券；以及
发送模块，用于发送所述个性化优惠券。
15.根据权利要求14所述的装置，其中，所述用户操作数据包括实时的用户操作数据和历史的用户操作数据；以及
所述第二获取模块具体用于根据实时的用户操作数据和历史的用户操作数据确定所述用户的适用优惠券。
16.根据权利要求15所述的装置，其中，所述用户属性包括购买力范围和/或优惠券敏感度。
17.根据权利要求14所述的装置，其中，
所述过滤模块包括：
第一获取单元，用于获取第一指定时长阈值内的历史的用户操作数据，作为第一用户操作数据，
第一确定单元，用于根据所述第一用户操作数据和第一模型确定用户的购买力范围；
并且/或者
所述过滤模块包括：
第二获取单元，用于获取第二指定时长阈值内的历史的用户操作数据，作为第二用户操作数据，以及
第二确定单元，用于根据所述第二用户操作数据和第二模型确定用户的优惠券敏感度。
18.根据权利要求15所述的装置，其中，所述第二获取模块包括：
第三确定单元，用于根据实时的用户操作数据确定所述用户的第一适用优惠券；
第四确定单元，用于根据历史的用户操作数据确定所述用户的第二适用优惠券；以及
第三获取单元，用于根据所述用户的第一适用优惠券以及所述用户的第二适用优惠券得到所述用户的适用优惠券。
19.根据权利要求18所述的装置，其中，所述第三确定单元包括：
记录子单元，用于通过页面埋点记录用户操作数据；
第一发送子单元，用于将脱密后的用户操作数据发送给kafka集群；以及
第一获取子单元，用于根据所述kafka集群中存储的用户操作数据和基于storm分布式计算框架的第一推荐模型得到所述用户的第一适用优惠券。
20.根据权利要求18所述的装置，其中，所述第四确定单元包括：
解析子单元，用于对页面埋点日志进行etl解析，得到解析结果；
存储子单元，用于将脱密的解析结果存储在离线数据表中；以及
第二获取子单元，用于根据所述离线数据表中的用户操作数据和基于hadoop的分布式计算框架的第三推荐模型得到所述用户的第二适用优惠券。
21.一种计算机系统，包括：
一个或多个处理器；
存储装置，用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现根据权利要求1～13中任一项所述的方法。
22.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时实现根据权利要求1～13中任一项所述的方法。
技术总结