CN111415179A

CN111415179A - 用户权益信息处理方法、装置及电子设备

Info

Publication number: CN111415179A
Application number: CN201910008518.2A
Authority: CN
Inventors: 马立铭; 吴心哲
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Shenzhen Technology Co ltd
Priority date: 2019-01-04
Filing date: 2019-01-04
Publication date: 2020-07-14
Anticipated expiration: 2039-01-04
Also published as: CN111415179B

Abstract

本申请实施例公开了用户权益信息处理方法、装置及电子设备，所述方法包括：接收至少一个第一用户发送的请求信息，所述请求信息中包括至少一项实质权益，并汇集所述第一用户发送的请求信息，生成实质权益池；根据所述实质权益池中的至少一项实质权益生成至少一项前置权益，建立前置权益与实质权益之间的关联关系；将所述前置权益发放给第二用户；在对所述前置权益进行核销的情况下，将所述前置权益转换成关联的实质权益，并存入所述第二用户关联的账户中。通过本申请实施例，降低用户权益发放过程中的成本，提高效率以及发放效果，降低资源浪费。

Description

用户权益信息处理方法、装置及电子设备

技术领域

本申请涉及用户权益信息处理技术领域，特别是涉及用户权益信息处理方法、装置及电子设备。

背景技术

在网络销售***中，无论是平台还是依托于平台的商家，做好拉新(以新增用户数为指标)、促活与留存(促进产品的活跃度并留住拉新进来的用户，直接指标是活跃用户数)都是重要的运营目标，而向用户发放诸如优惠券、红包、购物津贴等用户权益就是具体的手段之一。

在精细化、智能化运营的趋势下，针对用户权益发放这一点，商家希望能够提高权益发放的效率与精准度，以获取商家收益的最大化；而平台则希望能够利用平台的优势与能力来赋能商家，进而撬动商家在平台上的更大资源投入(权益出资金额和货品供给)，以获取平台收益的最大化。

通常情况下，平台一般会提供给商家一个后台运营***，甚至会引入第三方电商服务机构为商家提供更加丰富的运营功能，但由于其商家自运营的本质特点，如果商家要进行一次营销活动，往往需要其自身投入一定的人力资源持续跟进营销活动的各个细节，且作用范围被限制在店铺私域，营销效果有限。另一方面，平台本身也会有拉新、促活与留存的营销诉求，这种情况一般会由平台出资，以平台为主体实施营销活动方案，与商家的合作并不深入，或者商家参与的意愿不是十分强烈。可以看出，平台和商家的营销，目前是两套相对隔离的体系，造成了各自的成本压力和效率不高、效果不佳的问题。

发明内容

本申请实施例提供了用户权益信息处理方法、装置及电子设备，降低用户权益发放过程中的成本，提高效率以及发放效果，降低资源浪费。

本申请提供了如下方案：

一种用户权益信息处理方法，包括：

接收至少一个第一用户发送的请求信息，所述请求信息中包括至少一项实质权益，并汇集所述第一用户发送的请求信息，生成实质权益池；

根据所述实质权益池中的至少一项实质权益生成至少一项前置权益，建立前置权益与实质权益之间的关联关系；

将所述前置权益发放给第二用户；

在对所述前置权益进行核销的情况下，将所述前置权益转换成关联的实质权益，并存入所述第二用户关联的账户中。

一种用户权益信息处理方法，包括：

接收第二用户对目标页面的访问请求；

从服务端获得所述目标页面的页面数据，所述页面数据中包括待发放的前置权益信息，所述前置权益是通过对至少一个第一用户需发放的至少一项实质权益进行汇总后生成的；

根据所述页面数据展示所述目标页面时，提供关于所述前置权益的信息，以便通过对所述前置权益进行核销的方式，将所述前置权益转换成关联的实质权益。

一种用户权益信息处理方法，包括：

根据所述实质权益池，生成多个实质权益组合，每个组合中包括至少一项实质权益；

确定所述实质权益组合对应的触发条件信息；

在获得满足所述触发条件的操作信息的情况下，从所述实质权益组合中选择目标实质权益，并向关联的第二用户进行发放。

一种用户权益信息处理装置，包括：

请求信息接收单元，用于接收至少一个第一用户发送的请求信息，所述请求信息中包括至少一项实质权益，并汇集所述第一用户发送的请求信息，生成实质权益池；

前置权益生成单元，用于根据所述实质权益池中的至少一项实质权益生成至少一项前置权益，建立前置权益与实质权益之间的关联关系；

前置权益发放单元，用于将所述前置权益发放给第二用户；

前置权益核销单元，用于在对所述前置权益进行核销的情况下，将所述前置权益转换成关联的实质权益，并存入所述第二用户关联的账户中。

一种用户权益信息处理装置，包括：

访问请求接收单元，用于接收第二用户对目标页面的访问请求；

页面数据获得单元，用于从服务端获得所述目标页面的页面数据，所述页面数据中包括待发放的前置权益信息，所述前置权益是通过对至少一个第一用户需发放的至少一项实质权益进行汇总后生成的；

页面展示单元，用于根据所述页面数据展示所述目标页面时，提供关于所述前置权益的信息，以便通过对所述前置权益进行核销的方式，将所述前置权益转换成关联的实质权益。

一种用户权益信息处理装置，包括：

权益组合单元，用于根据所述实质权益池，生成多个实质权益组合，每个组合中包括至少一项实质权益；

触发条件确定单元，用于确定所述实质权益组合对应的触发条件信息；

权益发放单元，用于在获得满足所述触发条件的操作信息的情况下，从所述实质权益组合中选择目标实质权益，并向关联的第二用户进行发放。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

将所述前置权益发放给第二用户；

在对所述前置权益进行核销时的情况下，将所述前置权益转换成关联的实质权益，并存入所述第二用户关联的账户中。

一种电子设备，包括：

一个或多个处理器；以及

接收第二用户对目标页面的访问请求；

一种电子设备，包括：

一个或多个处理器；以及

确定所述实质权益组合对应的触发条件信息；

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

通过本申请实施例，通过平台赋能商家(第一用户)，第一用户需要向第二用户发放的实质权益只要进了活动权益池，平台就可以提供第一用户全托管式服务，权益发放的节奏、策略，以及搭配的流量引导都由平台提供，减轻第一用户运营负担。并且，相比单一的权益发放，由于引入前置权益和实质权益两级发放机制，使得本申请实施例能够适应更多的应用场景，也使得平台对于权益发放的调控空间变大。另外，由于平台能够为第一用户高效达成权益的有效发放等核心诉求，从而可以吸引更多第一用户的参与，权益池中的实质权益丰富度形成规模优势，使得平台的拉新、促活与留存成本维持在较低的水平，能够支撑平台常态化运营，且保持平台对第二用户持续的吸引力，形成平台和第一用户的良性循环。同时，通过平台对投放渠道、投放策略的把控，也可以使得第一用户发放的实质权益能够得到更有效的利用，降低资源浪费的概率。

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

附图说明

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

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

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

图3是本申请实施例提供的第一用户提交的实质权益示意图；

图4是本申请实施例提供的前置权益数据结构示意图；

图5是本申请实施例提供的另一***架构示意图；

图6-1至6-3是本申请实施例提供的第二客户端的用户界面示意图；

图7是本申请实施例提供的数据流向示意图；

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

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

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

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

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

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

具体实施方式

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

在本申请实施例中，为了能够更好地向商家(也可以称为卖家等，在本申请实施例中称为“第一用户”，相应的，将消费者用户、买家用户等称为“第二用户”)赋能，将平台的前台营销表达与运营能力、数据算法能力、权益发放能力、流量分发能力打包提供给第一用户，形成一套能够正向促进第一用户与平台收益的机制，实现第一用户与平台共赢的商业闭环。第一用户在不增加人员与技术投入的条件下，通过平台所提供的服务，实现更高效率和精准度的权益发放，甚至还可以得到店铺导流或者品牌触达，平台则通过技术与商业赋能，促进更多第一用户的参与，使得平台的拉新、促活与留存成本维持在较低的水平，且保持平台对第二用户持续的吸引力，形成良性循环。

具体实现时，本申请实施例中，可以由网络销售***的平台方组织具体的活动，并且可以向第一用户提供活动报名入口，通过该报名入口，第一用户可以提交所需发放的用户权益的信息。然后，平台可以对第一用户提交的用户权益进行汇总，生成另一种形式的权益，通过该另一种形式的权益，使得权益发放策略和节奏的调控有了更大的可运营空间。其中，在本申请实施例，将第一用户通过活动报名入口提交的需要发放的用户权益称为“实质权益”，将前述由平台组织生成的另一种形式的权益称为“前置权益”。也就是说，平台方可以将多个第一用户的待发放的实质权益汇集在一起，统一进行运营，使得具体的权益可以通过更大流量的入口进行投放，另外，也使得具体的权益发放策略得到统一的管理以及调控。在可选的方式下，还可以将实质权益的发放与第二用户取得前置权益之间设置一个时间差或指定一个统一发放的时间点，从而很方便地达到二次召回第二用户的目的。

从***架构角度而言，参见图1，具体可以包括网络销售***的服务端，提供给第一用户的第一客户端，以及提供给第二用户的第二客户端。其中，第一客户端具体可以用于展示具体的活动报名入口等信息，并提交具体的实质权益信息。服务端则可以用于对实质权益进行汇集，并通过一定的策略生成前置权益，并向第二用户进行发放。第二客户端可以用户对具体的前置权益进行领取，还可以通过完成一些具体的邀请、购物等操作来达成某些触发条件，在领取到具体的前置权益后，则还可以进行前置权益的核销，以兑换成实质权益。其中，具体的服务端可以部署在云端，为多个第一用户、第二用户的客户端提供具体的服务以及数据支持，第一客户端、第二客户端可以以独立的应用程序App的形式存在，也可以以网页等形式存在，用户可以通过在手机等移动设备上安装具体的App，或者通过移动终端设备、PC等设备访问网页的方式，与服务端形成互动。

下面对具体的实现方案进行详细介绍。

实施例一

首先，该实施例一从服务端的角度，提供了一种用户权益信息处理方法，参见图2，该方法具体可以包括：

S201：接收至少一个第一用户发送的请求信息，所述请求信息中包括至少一项实质权益，并汇集所述第一用户发送的请求信息，生成实质权益池；

具体实现时，平台服务端可以通过招商***等创建活动报名入口，第一用户通过第一客户端访问招商***，即可将实质权益报名提交到服务端。这一步骤是第一用户需要完成的主要步骤，后续的运营等具体操作则交由平台方托管，第一用户无需投入人力资源跟进。

其中，具体的实质权益可以有多种具体的类型，例如，可以包括“红包”等现金类型的权益；还可以包括“优惠券”等与具体第一用户绑定的、只能在第一用户店铺内部使用的权益，这种优惠券通常有一定的面额，例如，10元优惠券，30元优惠券，50元优惠券等；另外还可以包括“购物津贴”等能够在跨店使用的权益，例如，“满1000减200”的津贴等；再者还可以包括一些定向价格的商品对象，或者一些电影票等电子票据，等等。第一用户在参加活动时，可以选择具体的实质权益类型，对于“红包”、“津贴”等类型的实质权益，只需要设置具体的出资额即可，例如，某第一用户为“红包”类型的实质权益出资1000元，为“津贴”类型的实质权益出资2000元，等等。另外，关于“优惠券”类型的实质权益，由于通常是与第一用户绑定的，并且通常是通过其他的相关***创建或者生成的，因此，可以通过导入到上述招商***的方式来实现对该类型实质权益的提交。总之，每个参加活动的第一用户都可以设定需要发放的实质权益的类型，另外，对于一些与现金相关的实质权益，还可以给定具体的出资额等信息，之后，服务端可以进行保存。例如，一种方式下，具体保存的信息可以如表1所示：

表1

完成招商之后，如图3所示，服务端便可以对第一用户的报名信息进行汇总，生成实质权益池。实质权益池中可以包括一种或多种具体的实质权益，在实际应用中，通常是多种，并且对应多个不同的第一用户。其中，关于红包、津贴等类型的实质权益，可以将各个第一用户的出资额汇总在一起，计算出出资总额。另外，平台方还可以在此基础上进行出资。例如，某次活动中共有20个第一用户参加，其中，这20个第一用户对“红包”类型的总出资额是10万元，对“津贴”类型的总出资额是20万元；平台方还可以为“红包”类型的实质权益出资5万元，为“津贴”类型的实质权益出资10万元，使得实质权益池中的“红包”类型的实质权益的出资总额为15万元，“津贴”类型的实质权益的出资总额为30万元，等等。也就是说，在实质权益的出资结构上，可由单一第一用户出资、多个第一用户共同出资、还可以由第一用户与平台混合出资。使得实际能够向用户发放的实质权益的总额得以提升，相应的，第二用户也获得领取到更多实质权益的机会。例如，原来仅是第一用户来发红包时，由于一个第一用户的出资额有限，因此，第二用户实际领取到的“红包”等可能会数额会比较小，领取到之后很可能会被第二用户所忽略，以至于造成资源浪费。但是，在本申请实施例中，由于丰富了实质权益的出资结构，因此，使得权益池中每一项具体实质权益的出资总额得以累加，因此，在更高基数的基础上进行权益发放时，才可能使得至少部分用户获得相对较高的权益，也有利于提升权益的实际使用率。

S202：根据所述实质权益池中的至少一项实质权益生成至少一项前置权益，建立前置权益与实质权益之间的关联关系；

在获得实质权益池之后，服务端可以根据权益池中的各项具体的实质权益，生成一项或者多项前置权益，并且可以记录前置权益与实质权益之间的关联关系。其中，所谓的前置权益，属于一种在实质权益基础上另外包装成的一种权益对象，该前置权益本身不对应具体的红包金额或者优惠券面额等具体的权益，但是，它是多种实质权益的组合。也即，一项前置权益通常可以包括多种不同类型的实质权益，例如，如图4所示，一项前置权益中可以包括“定向价格商品”、“电影票”、“店铺优惠券”、“购物红包”等四种不同的实质权益。其中，关于“购物红包”等与现金等相关的实质权益，在一项前置权益中可以设定该前置权益关联的购物红包的总额，其可能是权益池中购物红包对应的总出资额的一部分，其他部分的出资额可能会被分配到其他的前置权益中，等等。后续具体在第二用户进行发放时，可以对前置权益进行发放，第二用户领取后，对前置权益进行核销时，将会将该前置权益兑换成其关联的各项实质权益中的其中一项，进而，第二用户实际获得的是兑换后确定出的其中一项实质权益。

其中，前置权益的具体形式可以是虚拟的“宝箱”、“金蛋”等多种不同的形式，也即，前端的第二用户具体领取到的可以上述“宝箱”、“金蛋”等，然后，通过“开启宝箱”、“砸金蛋”等形式进行前端权益的核销，并兑换出具体的红包、优惠券、购物津贴等实质权益。

具体在生成前置权益时，可以由平台方的工作人员等按照一定的营销活动需求等，将各项实质权益进行组合，生成前置权益。或者，也可以预先制定一定的自动化判断规则，然后由服务器自动生成前置权益。总之，可以将不同的实质权益进行组合，满足业务在不同场景发放不同类型权益的诉求。其中，对于存在面额信息的实质权益，可以根据面额信息的不同，生成多项不同的前置权益(当然，每项前置权益中还可以包括其他的不存在面额信息的实质权益，例如，红包等)。此时，根据所述多项前置权益分别关联的实质权益的面额特征信息，通过不同的渠道分别进行发放。比如，将符合第一面额特征的实质权益关联的前置权益向公域页面中进行发放，将符合第二面额特征的实质权益关联的前置权益向所述第二用户关联的私域页面中进行发放。具体如，将面额较小的“优惠券”权益组成普通前置权益，将面额较大的“优惠券”权益组成大额前置权益，分别在公域和私域(对应某个具体第二用户的店铺页面等)发放，另外还可以在所述公域页面内提供向所述第一用户关联的私域页面进行引流的引导信息，这样可以有效提高公域向私域的流量引导效果。

在生成了具体一项前置权益时，还可以对该前置权益的一些相关信息进行配置，例如，其中可以包括有效时间，发放的触发条件(相应的，对于第二用户而言就是“领取”的触发条件)，另外还可以对一项前置权益内各项实质权益的命中概率等核销策略进行控制。

其中，所谓的有效时间也就是指前置权益的有效使用期限等信息，例如，从某日到某日可以使用，等等。前置权益有效期的设定，可以增加第二用户核销前置权益的紧迫感，进一步提高第二用户参与的粘性，提供更多运营方式设计的空间。

所谓的发放触发条件，也即，在满足什么样的条件下，能够向第二用户进行前置权益的发放，相应的，第二用户可以对该前置权益进行领取。也就是说，第二用户在领取前置权益需要一个触发条件，其中，一个触发条件可以只关联一个前置权益，而一个前置权益可以被多个触发条件关联。

具体实现时，所谓的触发条件可以包括同步触发条件以及异步触发条件。其中，所谓的同步触发条件也就是在第二用户触发时，***将立即向该第二用户发放前置权益。例如，在接收到所述第二用户对投放有前置权益信息的页面的访问请求后，向所述第二用户发放所述同步触发条件对应的前置权益。也就是说，在接收到所述第二用户对投放有前置权益信息的页面的访问请求后，针对对应有异步触发条件的前置权益，提供达成所述异步触发条件所需的操作方式的引导信息。

而异步触发条件是指，需要引导第二用户进一步做出动作(如分享回流、下单等)，当满足条件后***才会向该第二用户发放前置权益。其中，具体的达成所述异步触发条件所需的操作方式可以有多种，例如，可以包括从当前页面跳转到指定页面，或者，通过社交网络***邀请其他用户参与当前活动的操作，或者，通过交易子***执行的商品对象相关操作(购买，加入“购物车”，关注，收藏等)，等等。其中，具体在以“从当前页面跳转到指定页面”作为触发条件时，通常可以是指从活动首页向具体第一用户的私域页面进行的跳转操作等等。其中，具体第一用户就可以是参加当前营销活动的第一用户，也即，只要为具体的实质权益进行了出资，则可以获得引流到其私域页面的机会。其中，针对一项前置权益，可以选项向参加当前营销活动的第一用户中的一部分进行导流，例如，某前置权益中关联的实质权益仅与其中的一部分第一用户相关，此时，可以仅将这部分第一用户与该前置权益关联。也就是说，具体一项前置权益关联哪些具体的第一用户，也是可以配置的，该配置的过程可以由平台方的工作人员手动完成，也可以通过预先建立的规则等由计算机程序自动完成。另外，具体在对第二用户进行引导时，由于一个前置权益关联着多个第二用户，因此，具体向哪个第一用户的私域页面进行引导，也是需要确定的问题。对此，在具体实现时，可以有多种方式来实现，例如，一种最简单的方式可以是随机选择一个第一用户向第二用户进行引导。或者，在另一种方式下，还可以根据当前第二用户的个性化偏好信息、历史行为数据、用户基本信息等，从当前前置权益关联的多个第一用户中选择出一个当前第二用户最可能感兴趣的一个第一用户，并引导该第二用户跳转到该第一用户关联的私域页面，然后，在该第二用户完成跳转后，再向该第二用户发放具体的前置权益，等等。这样，由于引导的过程考虑到了第二用户的个性化信息，因此，可以获得更高的引导成功率。

总之，在生成一项前置权益之后，可以配置同步触发条件，或者，上述任意一种或多种异步触发条件，这样，后续在向第二用户发放具体的前置权益时，可以根据第二用户实际满足的触发条件，进行对应的前置权益的发放。

关于核销策略具体是指，对于一项前置权益而言，在具体进行核销时，例如，第二用户领取了一个“金蛋”，具体在执行“砸”的动作时，需要兑换成一项具体的实质权益。但是，由于一项前置权益可能会关联有多项实质权益，因此，具体兑换成其中的哪项实质权益就是需要确定的问题。为此，可以在生成前置权益后，对具体的核销策略进行设定。具体在设定核销策略时，可以对同一前置权益关联的多项实质权益各自的命中概率进行设定。例如，某前置权益关联有三项实质权益，可以将其中“红包”的命中概率设定为50％，“优惠券”的命中概率设定为30％，“津贴”的命中概率设定为20％，等等。这样，在具体进行核销时，还可以根据预置的算法，以及上述各种实质权益的命中概率，确定出具体兑换成哪种实质权益。

也就是说，平台在汇总完活动报名权益后，将实质权益按营销活动需求，形成提供营销活动前台与消费者交互的前置权益组合，前置权益可由一项或多项实质权益组成，权益出资结构上，可由单一商家出资、多商家出资、商家与平台混合出资。之后，可以通过人工或者算法自动化的方式，为具体的前置权益设定触发条件，另外还可以针对对应有多项实质权益的前置权益设定核销策略，确定出每项实质权益的命中概率，等等。

因此，在具体实现时，前置权益本身的设置项可以包括对应的活动标识、主报第一用户的ID、有效期相关信息等，还可以通过一种结构化描述方式(如图4所示)与实质权益进行关联，主要字段可以包括：前置权益名称、前置权益ID、前置权益的触发条件、前置权益核销时各实质权益被命中核销的概率(0到1之间的小数)，等等。需要说明的是，一个活动下可以有多个第一用户参与，如果前置权益的组织是以单个第一用户为维度的，则可以为该前置权益设置前述主报第一用户ID，关联实质权益时不再需要针对每项实质权益描述其第一用户ID。如果前置权益由多个第一用户的实质权益组成的，则可以在每项实质权益的描述中增加第一用户ID字段描述(如图4中的电影票权益描述)。在一种实现方式下，具体记录的前置权益的信息可以如表2所示：

表2

前置权益概念的引入丰富了平台和第一用户针对第二用户营销活动的抓手，使得权益发放策略和节奏的调控有了更大的可运营空间。并且，由于平台能够为第一用户高效达成权益发放和引导进店两大核心诉求，从而吸引更多第一用户的参与，权益池中的实质权益丰富度形成规模优势，使得平台的拉新、促活与留存成本维持在较低的水平，能够支撑平台常态化运营，且保持平台对消费者持续的吸引力，形成平台和第一用户的良性循环。另外，前置权益核销时各实质权益被命中核销的概率作为一个可实时修改的项，又增大了运营空间，可以根据业务的具体情况灵活调控各项实质权益的发放速率。

S203：将所述前置权益发放给第二用户；

在完成对具体前置权益的生成，并在必要的情况下完成具体触发条件、核销策略等信息的设定之后，便可以通过预置的渠道将所述前置权益发放给第二用户。其中，具体的渠道可以包括一些流量比较大的公域页面，或者，参与活动的第一用户的私域页面，或者，还可以通过一些社交网络平台等方式，向第二用户进行发放等等。

具体在某个渠道中进行发放时，如果具体的前置权益设定了触发条件信息，则还可以结合具体的触发条件进行前置权益的发放。例如，对于对应有实时触发条件的前置权益，可以在第二用户进入到具体的投放有这种前置权益的页面后，立即向该用户进行发放。具体如图6-1所示，在第二用户进入到活动主页时，可以自动获得两枚“彩蛋”，也即两项具体的前置权益，该第二用户可以直接通过“砸蛋”等方式对该前置权益进行核销，兑换成具体的实质权益。

而如果某页面中投放了对应有异步触发条件的前置权益，则可以在该页面中向第二用户提供引导信息，用于引导用户通过执行某种操作，来达成具体的触发条件，以获得领取前置权益的机会。例如，如图6-2所示，通过弹出浮层的方式展示出“进店找彩蛋”等字样的引导信息，引导用户进入到某个第一用户的店铺页面中领取前置权益，等等。或者，还可以提供“邀请好友”、“去购买”某件商品对象等引导信息。

在第二用户执行了具体的操作之后，还可以通过一些方式获得具体的操作结果信息，例如，是否正确跳转到指定的店铺页面，是否成功邀请到某个好友用户加入到当前活动，是否成功购买了某件商品对象，等等。

其中，由于第二用户执行具体的操作的时间，与具体的触发条件达成的时间可能会存在一定的时间间隔，并且可能需要其他的***甚至外部***的配合，才能够达成具体的触发条件，因此，在具体实现时，服务端还可以通过一些方式，来确定是否达成某触发条件。具体的，可以通过多种方式来实现，例如，对于具体的跳转到某指定页面这种触发条件而言，可以通过客户端接口调用通知的方式来获得相关的信息。具体实现时，为了使得客户端能够在完成跳转后向服务端上报一些具体的跳转结果信息，还可以在接收到所述从当前页面到指定页面的跳转请求时，可以在所述指定页面的网址信息中添加预置标识；之后，在接收到所述第二用户关联的客户端提交的完成页面跳转的通知消息后，向所述第二用户发放所述前置权益信息。例如，某第二用户从公域进入某第一用户的私域后，如图6-3所示，客户端识别出前述标记后可以执行额外的弹出浮层逻辑，在浮层中，由前端/客户端向服务端发起请求获取前置权益并展示给第二用户。

另外，如果具体的异步触发条件需要跳转到外部***中执行某种操作，则可以由外部***的服务端，将具体的操作结果提供给本申请实施例中的服务端，由服务端向对应的第二用户进行前置权益的发放。例如，可以从外部***获得邀请成功的消息，然后确定作为邀请发起方的第二用户，并向该第二用户发放所述前置权益信息。或者，也可以从外部***获得所述交易子***提供的购买成功的消息然后，确定所述相关操作对应的第二用户，并向该第二用户发放所述前置权益信息。这样，当第二用户再次打开具体的客户端，并进入到相关的活动主页面时，便可以查看到新领取到的前置权益的信息。或者，还可以在通过这种异步的方式向第二用户发放的前置权益后，向该第二用户推送***通知消息，提醒该第二用户打开相关的客户端并进入到相应的主页面进行领取，等等。

其中，从外部***获得相关数据/消息的方式也可以有多种，例如，一种方式下，可以是由外部***对具体的消息进行广播，本申请实施例中的服务端通过监听这种广播消息的方式获得具体的通知消息。或者，另一种方式下，也可以由外部***主动调用本申请实施例中的服务端的相关接口，将具体的通知消息提供给该服务端，等等。

S204：在对所述前置权益进行核销的情况下，将所述前置权益转换成关联的实质权益，并存入所述第二用户关联的账户中。

在第二用户领取了具体的前置权益的情况下，可以通过执行“砸”、“开启”等操作对具体的前置权益进行核销，具体在进行核销时，可以将前置权益转换成关联的实质权益，然后，存储第二用户关联的账户中。

其中，对于同一项前置权益关联了多项实质权益的情况下，如前文所述，可以预先配置具体的核销策略，也即，为多种不同的实质权益设定具体的命中概率。因此，具体在进行核销时，首先就可以确定出该前置权益关联的实质权益分别有哪些，以及各自对应的命中概率，然后，通过一定的算法，从中选择出其中一个作为目标实质权益，并将当前的前置权益兑换为该目标实质权益。

其中，具体在确定出目标实质权益后，如果是“优惠券”等具体的某项实质权益，则直接进行兑换即可，而如果是“红包”等需要在具体核销时来确定具体权益金额的情况，则还可以根据第二用户的个性化信息等，确定实际发送给该第二用户的金额。例如，如果某第二用户的历史购物记录显示，其经常购买一些比较高端的商品对象，则可以将发放给该第二用户的“红包”金额设定的比较高，反之相反，等等。

另外，具体实现时，关于同一前置权益关联的各项实质权益的命中概率可以是随着活动的进行灵活调整的。例如，一种调整方式可以是，根据所述实质权益池中各种实质权益的剩余量，调整所述命中概率。例如，某前置权益中，“红包”这种实质权益的命中概率比较高，但是，在活动进行了一段时间之后，发现权益池中的“红包”剩余金额已经很少，而其他类型的实质权益还剩余比较多，则可以适当降低“红包”的命中概率，提高其他类型的实质权益的命中概率，等等。这样，通过实质权益库存的变化和核销形成概率反馈机制，从而可以不断优化发放效率。

或者，还可以在活动进行的过程中，对第二用户群体实际对各种实质权益的敏感度进行统计，然后，可以通过所述敏感度调整所述命中概率。例如，通过统计发现，第二用户普遍对“津贴”这种实质权益的敏感度比较高，则可以提高这种类型的实质权益的命中率，等等。

上述对具体核销策略的调控方式，可以调控前置权益的组成结构，通过数据反馈调节实质权益与前置权益的关联关系，从而可以从平台角度最优化权益发放效率。

如图7所示，其提供了一种具体的应用中的示意图，首先，通过对第一用户需要发放的实质权益进行组合，可以生成多项前置权益，然后，可以对各项具体的前置权益设定触发条件，具体的触发条件可以包括同步触发条件、异步触发条件等。通过对异步触发条件的设定，可以实现对第二用户行为的引导，例如，引导第二用户进行商品对象的收藏、分享、进店、加购、下单等操作，在其执行了具体的操作并满足具体条件的情况下，可以向具体的第二用户发放前置权益。后续，可以通过第二用户主动或者被动(对应平台在指定的时间点进行统一核销)的方式对具体领取到的前置权益进行核销。对另外，还可以为具体的前置权益设定核销策略，对于关联有多项实质权益的前置权益，可以分别设定各项实质权益的命中概率。这样，在具体对前置权益进行核销时，可以根据具体的核销策略以及预置的算法等，将前置权益兑换成其关联的其中一项实质权益。另外，具体的核销策略还可以进行调控，具体可以根据权益池中具体实质权益的库存量，或者第二用户对各种实质权益的敏感度等，进行具体的调控，包括跳转具体某项实质权益的命中概率，或者，增加或者减少某项实质权益的量，等等。

总之，通过本申请实施例，通过平台赋能商家(第一用户)，第一用户需要向第二用户发放的实质权益只要进了活动权益池，平台就可以提供第一用户全托管式服务，权益发放的节奏、策略，以及搭配的流量引导都由平台提供，减轻第一用户运营负担。并且，相比单一的权益发放，由于引入前置权益和实质权益两级发放机制，使得本申请实施例能够适应更多的应用场景，也使得平台对于权益发放的调控空间变大。另外，由于平台能够为第一用户高效达成权益的有效发放等核心诉求，从而可以吸引更多第一用户的参与，权益池中的实质权益丰富度形成规模优势，使得平台的拉新、促活与留存成本维持在较低的水平，能够支撑平台常态化运营，且保持平台对第二用户持续的吸引力，形成平台和第一用户的良性循环。同时，通过平台对投放渠道、投放策略的把控，也可以使得第一用户发放的实质权益能够得到更有效的利用，降低资源浪费的概率。

实施例二

该实施例二是与实施例一相对应的，从第二用户对应的客户端的角度，提供了一种用户权益信息处理方法，参见图8，该方法具体可以包括：

S801：接收第二用户对目标页面的访问请求；

S802：从服务端获得所述目标页面的页面数据，所述页面数据中包括待发放的前置权益信息，所述前置权益是通过对至少一个第一用户需发放的至少一项实质权益进行汇总后生成的；

S803：根据所述页面数据展示所述目标页面时，提供关于所述前置权益的信息，以便通过对所述前置权益进行核销的方式，将所述前置权益转换成关联的实质权益。

其中，具体在提供关于所述前置权益的信息时，对于关联有同步触发条件的前置权益，可以直接提供关于已获得该前置权益的信息。

或者，对于关联有异步触发条件的前置权益，则可以提供达成所述异步触发条件所需的操作方式的引导信息。

实施例三

在前述实施例一、二中，提出了前置权益的概念，独立形成一层，可以方便与外部其他活动形成联动，或在自身活动内部与各个第二用户行为触发条件之间形成“一对一”和“一对多”两种关联关系。

而在该实施例三中，还提供了一种简化的解决方案，也即可以将前置权益与第二用户的行为触发条件合并，不再使用前置权益的概念，仅对第二用户行为触发条件的描述进行扩展，这样可以形成第二用户行为触发条件与实质权益组合之间一对一的关系，而一对多的关联，则通过在多个第二用户行为触发条件中重复配置多次相同的权益组合来完成。

具体的，参见图9，该实施例三提供了一种用户权益信息处理方法，该方法具体可以包括：

S901：接收至少一个第一用户发送的请求信息，所述请求信息中包括至少一项实质权益，并汇集所述第一用户发送的请求信息，生成实质权益池；

S902：根据所述实质权益池，生成多个实质权益组合，每个组合中包括至少一项实质权益；

S903：确定所述实质权益组合对应的触发条件信息；

S904：在获得满足所述触发条件的操作信息的情况下，从所述实质权益组合中选择目标实质权益，并向关联的第二用户进行发放。

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

与实施例一相对应，本申请实施例还提供了一种用户权益信息处理装置，参见图10，该装置具体可以包括：

请求信息接收单元1001，用于接收至少一个第一用户发送的请求信息，所述请求信息中包括至少一项实质权益，并汇集所述第一用户发送的请求信息，生成实质权益池；

前置权益生成单元1002，用于根据所述实质权益池中的至少一项实质权益生成至少一项前置权益，建立前置权益与实质权益之间的关联关系；

前置权益发放单元1003，用于将所述前置权益发放给第二用户；

前置权益核销单元1004，用于在对所述前置权益进行核销的情况下，将所述前置权益转换成关联的实质权益，并存入所述第二用户关联的账户中。

具体实现时，所述请求信息中还可以包括所述第一用户为所述实质权益提供的出资额信息；此时，该装置还可以包括：

出资总额确定单元，用于确定所述实质权益池中包括的至少一项实质权益对应的出资总额信息，以用于按照所述出资总额进行前置权益向实质权益的转换。

其中，所述前置权益生成单元具体可以用于：

对于存在面额信息的实质权益，根据面额信息的不同，生成多项不同的前置权益。

此时，所述前置权益发放单元具体可以用于：

根据所述多项前置权益分别关联的实质权益的面额特征信息，通过不同的渠道分别进行发放。

更为具体的，所述前置权益发放单元可以用于：

将符合第一面额特征的实质权益关联的前置权益向公域页面中进行发放，将符合第二面额特征的实质权益关联的前置权益向所述第二用户关联的私域页面中进行发放。

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

引导单元，用于在所述公域页面内提供向所述第一用户关联的私域页面进行引流的引导信息。

具体的，所述前置权益发放单元具体可以包括：

触发条件确定子单元，用于确定用于发放所述前置权益的触发条件信息；

发放子单元，用于为满足所述触发条件的第二用户发放所述前置权益。

其中，所述触发条件包括同步触发条件；

所述发放子单元具体可以用于：

在接收到所述第二用户对投放有前置权益信息的页面的访问请求后，向所述第二用户发放所述同步触发条件对应的前置权益。

或者，所述触发条件包括异步触发条件；

所述发放子单元具体可以用于：

在接收到所述第二用户对投放有前置权益信息的页面的访问请求后，根据对应有异步触发条件的前置权益，提供达成所述异步触发条件所需的操作方式的引导信息。

其中，所述达成所述异步触发条件所需的操作方式包括：

从当前页面跳转到指定页面。

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

标识添加单元，用于接收到所述从当前页面到指定页面的跳转请求时，在所述指定页面的网址信息中添加预置标识；

第一发放子单元，用于接收到所述第二用户关联的客户端提交的完成页面跳转的通知消息后，向所述第二用户发放所述前置权益信息。

或者，所述达成所述异步触发条件所需的操作方式包括：通过社交网络***邀请其他用户参与当前活动的操作。

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

第一消息获得单元，用于获得邀请成功的消息；

第二发放子单元，用于确定作为邀请发起方的第二用户，并向该第二用户发放所述前置权益信息。

或者，所述达成所述异步触发条件所需的操作方式包括：通过交易子***执行的商品对象相关操作。

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

第二消息获得单元，用于获得所述交易子***提供的操作成功的消息；

第三发放子单元，用于确定所述相关操作对应的第二用户，并向该第二用户发放所述前置权益信息。

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

命中概率确定单元，用于在所述前置权益关联多种不同的实质权益时，确定所述前置权益关联的各种不同实质权益的命中概率；

所述前置权益核销单元具体可以用于：

根据所述命中概率以及预置的算法，从所述前置权益关联的多项实质权益中确定目标实质权益，并将所述前置权益兑换成所述目标实质权益。

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

第一核销策略调控单元，用于根据所述实质权益池中各种实质权益的剩余量，调整所述命中概率。

第二核销策略调控单元，用于统计获得第二用户群体对各种实质权益的敏感度，通过所述敏感度调整所述命中概率。

与实施例二相对应，本申请实施例还提供了一种用户权益信息处理装置，参见图11，该装置具体可以包括：

访问请求接收单元1101，用于接收第二用户对目标页面的访问请求；

页面数据获得单元1102，用于从服务端获得所述目标页面的页面数据，所述页面数据中包括待发放的前置权益信息，所述前置权益是通过对至少一个第一用户需发放的至少一项实质权益进行汇总后生成的；

页面展示单元1103，用于根据所述页面数据展示所述目标页面时，提供关于所述前置权益的信息，以便通过对所述前置权益进行核销的方式，将所述前置权益转换成关联的实质权益。

其中，所述页面展示单元具体可以用于：

对于关联有同步触发条件的前置权益，提供关于已获得该前置权益的信息。

或者，对于关联有异步触发条件的前置权益，提供达成所述异步触发条件所需的操作方式的引导信息。

与实施例三相对应，本申请实施例还提供了一种用户权益信息处理装置，参见图12，该装置具体可以包括：

请求信息接收单元1201，用于接收至少一个第一用户发送的请求信息，所述请求信息中包括至少一项实质权益，并汇集所述第一用户发送的请求信息，生成实质权益池；

权益组合单元1202，用于根据所述实质权益池，生成多个实质权益组合，每个组合中包括至少一项实质权益；

触发条件确定单元1203，用于确定所述实质权益组合对应的触发条件信息；

权益发放单元1204，用于在获得满足所述触发条件的操作信息的情况下，从所述实质权益组合中选择目标实质权益，并向关联的第二用户进行发放。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

将所述前置权益发放给第二用户；

另一种电子设备，包括：

一个或多个处理器；以及

接收第二用户对目标页面的访问请求；

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

一个或多个处理器；以及

确定所述实质权益组合对应的触发条件信息；

其中，图13示例性的展示出了电子设备的架构，具体可以包括处理器1310，视频显示适配器1311，磁盘驱动器1312，输入/输出接口1313，网络接口1314，以及存储器1320。上述处理器1310、视频显示适配器1311、磁盘驱动器1312、输入/输出接口1313、网络接口1314，与存储器1320之间可以通过通信总线1330进行通信连接。

其中，处理器1310可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器1320可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1320可以存储用于控制电子设备1300运行的操作***1321，用于控制电子设备1300的低级别操作的基本输入输出***(BIOS)。另外，还可以存储网页浏览器1323，数据存储管理***1324，以及用户权益信息处理***1325等等。上述用户权益信息处理***1325就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器1320中，并由处理器1310来调用执行。

输入/输出接口1313用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口1314用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1330包括一通路，在设备的各个组件(例如处理器1310、视频显示适配器1311、磁盘驱动器1312、输入/输出接口1313、网络接口1314，与存储器1320)之间传输信息。

另外，该电子设备1300还可以从虚拟资源对象领取条件信息数据库1341中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器1310、视频显示适配器1311、磁盘驱动器1312、输入/输出接口1313、网络接口1314，存储器1320，总线1330等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

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

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

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

Claims

1.一种用户权益信息处理方法，其特征在于，包括：

将所述前置权益发放给第二用户；

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

所述请求信息中还包括所述第一用户为所述实质权益提供的出资额信息；

所述生成实质权益池之后还包括：

确定所述实质权益池中包括的至少一项实质权益对应的出资总额信息，以用于按照所述出资总额进行前置权益向实质权益的转换。

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

所述根据所述实质权益池中的至少一项实质权益生成至少一项前置权益，包括：

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

所述将所述前置权益发放给第二用户，包括：

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

所述通过不同的渠道分别进行发放，包括：

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

在所述公域页面内提供向所述第一用户关联的私域页面进行引流的引导信息。

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

所述将所述前置权益发放给第二用户，包括：

确定用于发放所述前置权益的触发条件信息；

为满足所述触发条件的第二用户发放所述前置权益。

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

所述触发条件包括同步触发条件；

所述为满足所述触发条件的第二用户发放所述前置权益，包括：

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

所述触发条件包括异步触发条件；

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

所述达成所述异步触发条件所需的操作方式包括：

从当前页面跳转到指定页面。

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

接收到所述从当前页面到指定页面的跳转请求时，在所述指定页面的网址信息中添加预置标识；

接收到所述第二用户关联的客户端提交的完成页面跳转的通知消息后，向所述第二用户发放所述前置权益信息。

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

所述达成所述异步触发条件所需的操作方式包括：

通过社交网络***邀请其他用户参与当前活动的操作。

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

获得邀请成功的消息；

确定作为邀请发起方的第二用户，并向该第二用户发放所述前置权益信息。

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

所述达成所述异步触发条件所需的操作方式包括：

通过交易子***执行的商品对象相关操作。

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

获得所述交易子***提供的操作成功的消息；

确定所述相关操作对应的第二用户，并向该第二用户发放所述前置权益信息。

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

在所述前置权益关联多种不同的实质权益时，确定所述前置权益关联的各种不同实质权益的命中概率；

所述将所述前置权益兑换成关联的实质权益，包括：

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

根据所述实质权益池中各种实质权益的剩余量，调整所述命中概率。

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

统计获得第二用户群体对各种实质权益的敏感度，通过所述敏感度调整所述命中概率。

19.一种用户权益信息处理方法，其特征在于，包括：

接收第二用户对目标页面的访问请求；

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

所述根据所述页面数据展示所述目标页面时，提供关于所述前置权益的信息，包括：

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

对于关联有异步触发条件的前置权益，提供达成所述异步触发条件所需的操作方式的引导信息。

22.一种用户权益信息处理方法，其特征在于，包括：

确定所述实质权益组合对应的触发条件信息；

23.一种用户权益信息处理装置，其特征在于，包括：

前置权益发放单元，用于将所述前置权益发放给第二用户；

24.一种用户权益信息处理装置，其特征在于，包括：

25.一种用户权益信息处理装置，其特征在于，包括：

26.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

将所述前置权益发放给第二用户；

27.根据权利要求26所述的电子设备，其特征在于，所述程序指令还用于执行权利要求2至18任一项所述的方法。

28.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

接收第二用户对目标页面的访问请求；

29.根据权利要求28所述的电子设备，其特征在于，所述程序指令还用于执行权利要求20或21所述的方法。

30.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

确定所述实质权益组合对应的触发条件信息；