CN112711722A - 数据处理与助力方法、设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种数据处理与助力方法、设备及存储介质。在本申请实施例中，第一用户通过邀请第二用户到应用中对其发生指定行为来为应用拉取用户，在第一用户请求第二用户到应用中对其发生指定行为的过程中嵌入资源分享机制，通过资源分享机制可增加第二用户参与的积极性，提升第二用户的参与度和参与效果，有利于快速提升应用的用户回流量。

Description

数据处理与助力方法、设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据处理与助力方法、设备及存储介质。

背景技术

在现有技术中，一些互联网应用面向种子用户提供拉人奖励机制。在该机制下，种子用户向新用户分享应用的相关链接，如果新用户通过种子用户分享的链接访问应用，应用会向种子用户提供优惠券、奖励金，或者提升种子用户的等级等，以鼓励种子用户。

但是，采用现有方式带来的用户回流效果并不理想，回流速度慢，回流量低，尤其是随着时间的推移，现有方式的用户回流效果会越来越差，面对用户回流亟需一种新的解决方案。

发明内容

本申请的多个方面提供一种数据处理与助力方法、设备及存储介质，用以快速提升应用的用户回流量。

本申请实施例提供一种数据处理方法，包括：显示第一链接指向的页面，所述第一链接是第一用户分享的；响应第二用户对所述页面上触发控件的操作，确定所述第二用户对所述第一用户发生指定行为；以及为所述第二用户获取所述第一用户分享的资源；其中，所述触发控件与所述指定行为对应。

本申请实施例还提供一种数据处理方法，包括：根据第一用户的分享请求，显示分享页面；基于所述分享页面，获取所述第一用户要分享的资源信息；基于所述资源信息生成资源分享所需的第一链接，所述第一链接指向的页面包含触发控件，所述触发控件与指定行为对应；将所述第一链接发送给第二用户，以使所述第二用户通过所述触发控件对所述第一用户发生指定行为并获取所述第一用户分享的资源。

本申请实施例还提供一种助力方法，包括：显示第一用户分享的第一链接；响应第二用户对所述第一链接的点击操作，显示所述第一链接指向的红包领取页面；响应所述第二用户对所述红包领取页面上助力控件的操作，对所述第一用户进行助力，并为所述第二用户获取所述第一用户分享的红包。

本申请实施例还提供一种助力方法，包括：根据第一用户的助力请求，显示红包分享页面；基于所述红包分享页面，获取所述第一用户要分享的红包信息；基于所述红包信息生成分享红包所需的第一链接，所述第一链接指向的红包领取页面包含助力控件；将所述第一链接发送给第二用户，以供所述第二用户通过所述助力控件为所述第一用户助力并获取所述第一用户分享的红包。

本申请实施例还提供一种计算机设备，包括：存储器、处理器和显示器；

所述显示器，用于显示第一链接指向的页面，所述第一链接是第一用户分享的；所述存储器，用于存储计算机程序；所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：响应第二用户对所述页面上触发控件的操作，确定所述第二用户对所述第一用户发生指定行为；以及为所述第二用户获取所述第一用户分享的资源；其中，所述触发控件与所述指定行为对应。

本申请实施例还提供一种计算机设备，包括：存储器、处理器和显示器；

所述显示器，用于根据第一用户的分享请求，显示分享页面；所述存储器，用于存储计算机程序；所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：基于所述分享页面，获取所述第一用户要分享的资源信息；基于所述资源信息生成资源分享所需的第一链接，所述第一链接指向的页面包含触发控件，所述触发控件与指定行为对应；将所述第一链接发送给第二用户，以使所述第二用户通过所述触发控件对所述第一用户发生指定行为并获取所述第一用户分享的资源。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当所述计算机程序被处理器执行时，致使所述处理器实现本申请实施例提供的任一项数据处理方法以及助力方法中的步骤。

在本申请实施例中，第一用户通过邀请第二用户到应用中对其发生指定行为来为应用拉取用户，在第一用户请求第二用户到应用中对其发生指定行为的过程中嵌入资源分享机制，通过资源分享机制可增加第二用户参与的积极性，提升第二用户的参与度和参与效果，有利于快速提升应用的用户回流量。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请示例性实施例提供的一种网络***的结构示意图；

图2为本申请示例性实施例提供的一种基于发红包的分享点赞流程示意图；

图3a-图3e为本申请示例性实施例提供的分享点赞流程中涉及到的部分界面的状态示意图；

图4为本申请示例性实施例提供的一种基于领红包的点赞流程示意图；

图5a-图5d为本申请示例性实施例提供的点赞流程中涉及到的部分界面的状态示意图；

图6a为本申请示例性实施例提供的发红包对应的后台数据处理流程的示意图；

图6b为本申请示例性实施例提供的领红包对应的后台数据处理流程的示意图；

图7a为本申请示例性实施例提供的一种数据处理方法的流程示意图；

图7b为本申请示例性实施例提供的另一种数据处理方法的流程示意图；

图8a为本申请示例性实施例提供的一种计算机设备的结构示意图；

图8b为本申请示例性实施例提供的另一种计算机设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

针对现有技术面临的用户回流问题，在本申请实施例中，第一用户通过邀请第二用户到应用中对其发生指定行为来为应用拉取用户，在第一用户请求第二用户到应用中对其发生指定行为的过程中嵌入资源分享机制，通过资源分享机制可增加第二用户参与的积极性，提升第二用户的参与度和参与效果，有利于快速提升应用的用户回流量。

图1为本申请示例性实施例提供的一种网络***的结构示意图。如图1所示，该网络***包括：服务端设备10a和至少两个终端设备10b。图1中所呈现的服务端设备10a和终端设备10b的实现形态只是示例性说明，并不对其做限定。

其中，服务端设备10a和各终端设备10b之间可以是无线或有线连接。可选地，服务端设备10a可以通过移动网络和终端设备10b通信连接，相应地，移动网络的网络制式可以为2G(GSM)、2.5G(GPRS)、3G(WCDMA、TD-SCDMA、CDMA2000、UTMS)、4G(LTE)、4G+(LTE+)、WiMax、5G以及未来可能出现的其它网络制式等中的任意一种。可选地，服务端设备10a也可以通过蓝牙、WiFi、红外线等方式和各终端设备10b通信连接。

在本实施例中，并不限定服务端设备10a的物理形态。服务端设备10a可以为单一服务器设备，也可以云化的服务器阵列，或者为云化的服务器阵列中运行的虚拟机(Virtual Machine，VM)。另外，服务端设备也可以指具备相应服务能力的其他计算设备，例如电脑、智能手机等运行有服务端程序的终端设备。

在本实施例中，终端设备10b是指用户使用的，具有用户所需计算、上网、通信等功能的计算机设备，例如可以是智能手机、平板电脑、个人电脑、穿戴设备等。终端设备10b通常包括至少一个处理单元和至少一个存储器。处理单元和存储器的数量取决于终端设备10b的配置和类型。存储器可以包括易失性的，例如RAM，也可以包括非易失性的，例如只读存储器(Read-Only Memory，ROM)、闪存等，或者也可以同时包括两种类型的。存储器内通常存储有操作***(Operating System，OS)、一个或多个应用软件，也可以存储有程序数据等。除了处理单元和存储器之外，终端设备10b也会包括网卡芯片、IO总线、音视频组件等基本配置。可选地，根据终端设备10b的实现形式，终端设备10b也可以包括一些***设备，例如键盘、鼠标、输入笔、打印机等。这些***设备在本领域中是众所周知的，在此不做赘述。

在本实施例中，终端设备10b上安装并运行客户端程序，可为用户提供本地服务。相应地，服务端设备10a上安装并运行与客户端程序对应的服务端程序，可响应终端设备10b的各种请求进行相应处理，并向终端设备10b返回处理结果，以及向终端设备10b提供资源、存储客户端的数据等等。根据终端设备10b上运行的客户端程序的不同，服务端设备10a上运行的服务端程序也会有所不同。

例如，服务端设备10a和终端设备10b上分别安装的服务端程序和客户端程序，可以分别是钉钉以及其它即时通信类应用的服务端程序和客户端程序。又例如，服务端设备10a和终端设备10b上安装的服务端程序和客户端程序，可以分别是outlook、foxmail等邮件类应用的服务端程序和客户端程序。又例如，服务端设备10a和终端设备10b上安装的服务端程序和客户端程序，可以分别是腾讯、优酷等视频播放类应用的服务端程序和客户端程序。又例如，服务端设备10a和终端设备10b上安装的服务端程序和客户端程序，可以分别是淘宝、天猫、京东、拼多多等购物类应用的服务端程序和客户端程序。

无论是哪种应用，增加用户流量都是应用一直关注并着力解决的主要问题之一。在本实施例中，以第一应用为例展开描述，第一应用可以是任一应用。第一应用可以采用一定机制或策略鼓励其访问用户为其邀请(或者拉取)用户，增加其用户流量。为便于描述，在本申请实施例中，将有资格为第一应用邀请其它用户的用户记为第一用户，将可被第一用户邀请的其它用户记为第二用户，第二用户包括但不限于：新用户和流失用户。

可选地，第一用户可以是在最近一段时间内访问过第一应用的任何用户，例如包括但不限于：第一应用的活跃用户，种子用户，在最近一段时间内第一次访问第一应用的用户，以及在最近一段时间内偶尔访问第一应用的用户。本实施例对最近一段时间的时间长度不做限定，可根据应用场景和应用需求灵活设定。其中，活跃用户是指根据应用的性质设置某个要求，达到该要求的用户。种子用户是指可以凭借自身的影响力，能吸引更多用户，是首批支持应用的用户。

在本实施例中，第一应用采用一种拉人机制鼓励第一用户为其拉取用户。该拉人机制要求第一用户邀请第二用户到第一应用中对其发生指定行为，从而达到为第一应用拉取用户的目的。在本实施例中，并不对“指定行为”进行限定，是拉人机制中要求或设定的行为，可根据应用场景灵活设定。举例说明，指定行为可以是点赞行为、入团行为或加血行为，也可以是评论行为、砍价行为、浏览指定商品的行为或代付行为，等等。

例如，以指定行为是点赞行为为例，第一用户为第一应用拉取第二用户的实质是邀请第二用户进入第一应用的指定页面为第一用户点赞，只有第二用户在第一应用的指定页面上为第一用户点赞成功，才意味着第一用户为第一应用成功拉取到第二用户。

又例如，以指定行为是入团行为为例，第一用户为第一应用拉取第二用户的实质是邀请第二用户进入第一应用的指定页面加入第一用户创建的团队，只有第二用户在第一应用的指定页面上成功加入第一用户创建的团队，才意味着第一用户为第一应用成功拉取到第二用户。

又例如，以指定行为是评论行为为例，第一用户为第一应用拉取第二用户的实质是邀请第二用户进入第一应用的指定页面针对第一用户发表评论，只有第二用户在第一应用的指定页面上成功对第一用户进行了评论，才意味着第一用户为第一应用成功拉取到第二用户。

进一步，在上述拉人机制中，在第一用户邀请第二用户进入第一应用中对其发生指定行为的过程中嵌入资源分享机制，通过资源分享机制可增加第二用户参与的积极性，提升第二用户的参与度和参与效果，有利于快速提升应用的用户回流量。在本申请实施例中，并不对第一用户分享的资源进行限定，可以是任何能够吸引第二用户的资源，例如可以是网络红包、优惠券、积分、流量、虚拟游戏币、话费等等。

在本申请下述实施例中，将分别从第一用户邀请第二用户角度和第二用户接受第一用户邀请的角度，对本申请实施例的技术方案展开说明。为便于描述和区分，将第一用户使用的终端设备记为第一终端设备，将第二用户使用的终端设备记为第二终端设备。其中，第一用户是有权限为第一应用邀请其它用户的用户，第二用户是需要被邀请的目标用户，第二用户的数量可以是一个，也可以是多个。

从第一用户邀请第二用户的角度，对本申请技术方案展开说明：

对第一用户来说，若希望为第一应用成功拉取第二用户，则需要邀请第二用户进入第一应用中并对其发生指定行为，为了达到该目的，第一用户可以向第二用户分享资源，以增加第二用户的参与度。基于此，第一用户可向第一终端设备发出分享请求。例如，第一用户可以进入第一应用提供的资源分享发起页面，在该资源分享发起页面上点击资源分享发起控件，从而发出分享请求。或者，第一用户也可以通过语音方式，向第一终端设备发出分享请求。

对第一终端设备来说，可根据第一用户的分享请求，显示分享页面。该分享页面是第一用户与第一终端设备之间的交互界面，第一终端设备可基于该分享页面获取第一用户要分享的资源信息，如图1所示。进而，可基于第一用户要分享的资源信息，生成资源分享所需的第一链接。如图1所示，该第一链接指向的页面包括触发控件，该触发控件与指定行为对应。换句话说，一旦该触发控件被触发，“对第一用户发生指定行为的操作”就会被执行。另外，第一链接指向的页面还具有让第二用户获取第一用户分享的资源功能，可称之为资源领取页面，因此，触发控件还可以触发“为第二用户获取第一用户分享的资源的操作”。如图1所示，在获得第一链接之后，第一终端设备可以将第一链接发送给第二用户(实际上是发送给第二终端设备)，以使第二用户通过第一链接指向的页面上的触发控件对第一用户发生指定行为并领取第一用户分享的资源。

在本实施例中，通过资源分享的第一链接，并在第一链接指向的页面上设置触发控件，并预先将该触发控件与“对第一用户发生指定行为的操作”与“为第二用户获取第一用户分享的资源的操作”绑定在一起，利用资源分享机制，有利于吸引第二用户进入第一链接指向的页面，借助于第二用户想要获取第一用户分享的资源的心理，可促使第二用户通过该触发控件对第一用户发生指定行为并获取第一用户分享的资源，有利于快速提升应用的用户回流量。

在本申请实施例中，并不限定第一终端设备基于分享页面，获取第一用户要分享的资源信息的实施方式。其中，第一用户要分享的资源信息可以包括但不限于：第一用户要分享的资源的类型、资源总量、资源个数等信息。

在一可选实施例中，分享页面上默认携带有第一用户要分享的资源信息，例如包括第一用户要分享的资源总量和资源个数等信息。基于此，第一终端设备可直接从分享页面中获取第一用户要分享的资源总量和资源个数等资源信息。

在另一可选实施例中，分享页面支持输入操作。借助于分享页面的输入功能，第一用户可以根据资源分享需求，在分享页面上输入要分享的资源总量和资源个数等资源信息。基于此，第一终端设备可响应第一用户在分享页面上的输入操作，获取第一用户输入的资源总量和资源个数等作为资源信息。

需要说明的是，本实施例中的分享页面可以支持多种输入方式，例如可以支持文本输入方式、语音输入方式或图像输入方式等等。

在一示例性实施例中，分享页面上包括语音输入控件，第一用户可点击该语音输入控件调起语音输入功能，输入要分享的资源信息。例如，第一用户可以输入语音信号：“我要分享10个随机红包，红包总金额为100元”，其中，10个随机红包以及红包总金额为100元是第一用户要分享的资源信息。又例如，第一用户可以输入语音信号：“我要分享5个流量包，总流量为200M”，其中，5个流量包以及总流量为200M是第一用户要分享的资源信息。对第一终端设备来说，可以获取第一用户在分享页面上输入的语音信号，从语音信号中解析出第一用户要分享的资源总量和资源个数等资源信息。

在另一示例性实施例中，分享页面上包括信息输入区域，第一用户可点击该信息输入区域调起信息输入功能，在信息输入区域内输入要分享的资源信息。如图1所示，该分享页面上包括资源总量对应的信息输入区域和资源个数对应的信息输入区域，第一用户可以两个信息输入区域内分别输入资源总量和资源个数。在图1中，以资源总量为100，资源个数为10为例进行图示。对第一终端设备来说，可以获取第一用户在分享页面上输入的文本信息，从而获取第一用户要分享的资源总量和资源个数等资源信息。

在另一示例性实施例中，分享页面上包含拍照控件，第一用户可以点击拍照控件对包含有第一用户要分享的资源信息的载体进行拍照，得到包含第一用户要分享的资源信息的图片，或者也可以点击拍照控件从图库中加载包含有第一用户要分享的资源信息的图片。第一终端设备可以对第一用户提供的图片进行识别，获取图片中包含的第一用户要分享的资源总量和资源个数等资源信息。

进一步，在本申请另一些实施例中，第一用户要分享的资源信息除了包括第一用户要分享的资源总量和资源个数之外，还可以包括指引文本信息。例如，第一用户以语音输入方式、文本输入方式或图像输入方式在分享页面上输入指引文本信息。可选地，以图1所示分享页面为例，该分享页面上还可以包括：指示文本信息对应的信息输入区域。在图1中，指示文本信息以“点赞，领红包”为例进行图示。第一终端设备来说，还可以获取第一用户在分享页面上输入的指引文本信息。

其中，指引文本信息体现资源分享与发生指定行为之间的关联关系，属于本次资源分享使用的文案用语。例如，指引文本信息可以是“帮我加油助力，领红包”、“伸出你的小胖手为我送上一个赞，还你一个清空购物车的机会”等等，具体可根据应用需求灵活设定。指引文本信息可以体现在第一链接中，还可以体现在第一链接指向的页面中。换句话说，第一链接和/或第一链接指向的页面可以包括指引文本信息。对第二用户来说，通过指引文本信息，可以获知一种信息，该信息是对第一用户发生指定行为后可获取第一用户分享的资源。

在获取第一用户要分享的资源信息之后，可基于该资源信息生成资源分享所需的第一链接。第一链接的生成过程，与资源分享对应的数据处理逻辑有关。资源分享对应的数据处理逻辑不同，生成第一链接的过程也会有所不同。在本实施例中，提供一种通过建立虚拟资源流方式实现资源分享。即，在资源分享过程中，采用中间账户，第一用户需要分享的资源实际存储在中间账户中，且在第二用户获取到第一用户分享的资源但并未发起资源转移请求的情况下，第二用户获取到的第一用户分享的资源不会从中间账户转移到第二用户，当第二用户针对获取到的资源发起资源转移请求时，第二用户获取到的资源会被直接从中间账户转移到资源转移涉及的第三方资源账户中。由此可见，在整个资源分享过程中，资源不会实际到达第二用户的资源账户中。

基于上述虚拟资源流方式实现的资源分享方案，若第一用户要分享的资源信息包括资源总量和资源个数，则生成第一链接的过程包括：根据资源总量，从第一用户的资源账户中转出相应资源到中间账户；根据资源个数，将资源总量拆分为N个可获取的资源分量，N表示资源个数，是正整数；根据触发控件和N个可获取的资源分量，生成第一链接。例如，可以在第一链接中添加触发控件，并将触发控件与N个可获取的资源分量相关联，这样在第二用户点击触发控件时，会触发从N个可获取的资源分量中为第二用户获取目标资源分量的操作。

进一步，在第一用户要分享的资源信息包括资源总量、资源个数和指引文本信息的情况下，生成第一链接的过程包括：根据资源总量，从第一用户的资源账户中转出相应资源到中间账户；根据资源个数，将资源总量拆分为N个可获取的资源分量，N表示资源个数，是正整数；根据触发控件、N个可获取的资源分量以及指引文本信息，生成第一链接。例如，可以在第一链接中添加触发控件和指引文本信息，并将触发控件与N个可获取的资源分量相关联，这样在第一链接上会体现指引文本信息，且在第二用户点击触发控件时，会触发从N个可获取的资源分量中为第二用户获取目标资源分量的操作。

需要说明的是，结合上述虚拟资源流方式，根据第一用户要分享的资源信息生成第一链接的操作，可在第一终端设备侧完成，也可以由服务端设备完成。在本申请各实施例中，重点关注描述由服务端设备完成的情况。对于由服务端设备完成的情况，第一终端设备需要向服务端设备提供第一用户要分享的资源信息，然后由服务端设备基于第一用户要分享的资源信息生成第一链接并返回给第一终端设备。服务端设备基于第一用户要分享的资源信息生成第一链接的过程参见前面描述，在此不再赘述。

在本申请上述可选实施例中，并未对资源总量、资源个数和指引文本信息进行任何限定，用户可以根据自己的分享需求，灵活、按需设置。当然，为了让资源分享更加合理，可以设置一些资源分享要求。例如，可以设置资源总量要求，用来将资源总量限定在合理范围，例如不能少于设定的下限值，如0.1，不能大于设定的上限值，如999。还可以设置资源个数要求，用来将资源个数限定在合理范围内，例如不能少于设定的下限值，如1个，不能大于设定的上限值，如99个。进一步，还可以设置用语规范，用来规范指引文本信息，例如不允许出现不文明用词、敏感字词等，不能超过最大字数限制等。这些要求可根据应用需求灵活设定。

基于上述，在申请一些实施例中，在基于分享页面，获取第一用户要分享的资源信息的过程中，还可以判断第一用户输入的资源总量是否满足设定的资源总量要求；判断第一用户输入的资源个数是否满足设定的资源个数要求；判断所述第一用户输入的指引文本信息是否符合设定的用语规范；若这些判断操作的判断结果均为是，则获取第一用户输入的资源总量、资源个数和指引文本信息作为资源信息。反之，若某一判断操作的判断结果为否，可以在分享页面上显示提示信息，提示第一用户重新输入该判断操作对应的资源信息。

可选地，在第一用户输入一种资源信息后，可以及时判断第一用户输入的该资源信息是否满足相应要求；若满足，则第一用户可以继续输入其它资源信息，若不满足，可提示第一用户需要重新输入。或者，也可以在第一用户将各种资源信息全部输入后，再判断各资源信息是否符合相应要求；若满足，则获取第一用户输入的资源信息；若不满足，则提示用户哪种资源信息不满足要求，要求用户重新输入。

在本申请上述可选实施例中，并未对第一用户进行资源分享的资格进行限定，这意味着第一用户可无限次且随时通过资源分享方式为第一应用拉取用户。当然，除此之外，也可以根据应用场景，设置一些规则对第一用户进行资源分享的次数和时间等进行合理限定。

例如，可以设定一轮或多轮分享活动，每轮分享活动包含至少一个活动时段。其中，每个活动时段设置允许资源分享的次数上限值，和/或，每一轮分享活动设置允许资源分享的次数上限。不同活动时段允许资源分享的次数上限值可以相同，也可以不相同。同理，对于不同轮次的分享活动允许资源分享的次数上限值可以相同，也可以不相同。在该场景中，第一用户需要在每轮分享活动期间的每个活动时段内进行资源分享，在该活动时段内分享资源的次数不能超过该活动时段允许的次数上限，和/或，在本轮分享活动中分享资源的次数不能超过本轮分享活动允许的次数上限，反之，则不能继续分享资源。

基于上述，在接收到第一用户的分享请求之后，在基于分享页面获取第一用户要分享的资源信息之前，还可以执行以下至少一种判断操作：

判断第一用户在本轮分享活动中分享资源的总次数是否已经达到本轮分享活动允许的次数上限；

判断第一用户在当前活动时段内分享资源的次数是否已经达到当前活动时段允许的次数上限；

若至少一种判断操作的判断结果均为否，说明第一用户具有资源分享资格，可以继续分享资源，则允许第一用户在分享页面上执行输入操作。若任一判断操作的判断结果为是，说明第一用户不再具备资源分享资格，无法继续分享资源，则可以通过禁止第一用户在分享页面上执行输入操作，达到禁止第一用户继续分享资源的目的。

第一用户分享第一链接之后，还可以再次发起分享请求，进入分享页面。在该场景中，第一用户之前已经分享的资源有可能还有剩余，为了便于第一用户了解之前已经分享的资源的状态以及相关信息，在分享页面上不仅允许第一用户重新输入新的资源信息，还会显示第一用户之前已经分享的资源的信息，供第一用户查看。进一步可选地，该分享页面上还会默认显示第一用户最近一次分享资源使用的资源信息。对第一终端设备来说，可根据第一用户再次发起的分享请求，显示分享页面，该分享页面上显示有第一用户已经分享的资源的信息。这里的信息包括但不限于：第一用户每次分享的资源的时间、每次分享的资源总量、每次分享的资源的个数，以及每次分享的资源的获取状态等。这里的获取状态表示该资源是否已经全部被获取完，还是仍有剩余。

进一步，第一用户再次发出分享请求时，第一用户之前已分享的资源可能会有剩余。鉴于此，为了便于第一用户继续进行资源分享，分享页面上还可以显示分享控件。第一用户可以点击该分享控件，继续对尚有剩余的资源进行分享。第一终端设备可响应第一用户对分享页面上分享控件的触发操作，继续将第一链接发送给第三用户，第三用户可以是任何未获取过第一用户分享的资源的用户。第三用户可以包括不同于第二用户的新用户，也可以包括并未获取第一用户分享的资源的第二用户。

在此说明，无论是向第二用户还是向第三用户发送第一链接，均不限定发送第一链接的方式。例如，第一终端设备可以将第一链接直接分享给钉钉及其它即时通讯类应用中的好友用户，也可以将第一链接直接分享给微博、知乎等其它社交类应用中的好友用户。或者，也可以复制第一链接，然后采用粘贴的方式将该链接分享给其它应用中的好友用户。

从第二用户接收第一用户邀请的角度，对本申请技术方案展开说明：

对第二用户来说，可接收第一用户分享的第一链接，通过对第一链接进行触发，可进入第一链接指向的页面。其中，对第一链接的触发包括但不限于：点击、长按、悬停、触控或双击等。参见图1，第二终端设备可显示第一链接指向的页面，在该页面上包括触发控件，该触发控件与指定行为对应。或者说，该触发控件绑定了“对第一用户发生指定行为的操作”，一旦该触发控件被触发，“对第一用户发生指定行为的操作”就会被执行。

对第二用户来说，可以对上述触发控件进行触发操作，也可以选择不对上述触发控件进行触发操作。在本实施例中，第一链接是资源分享的连接，第一链接指向的页面可视为资源领取页面，在一定程度上可吸引第二用户对触发控件进行触发操作。若第二用户对上述触发控件进行触发操作，第二终端设备可响应第二用户对上述触发控件的操作，确定第二用户对第一用户发生指定行为，并为第二用户获取第一用户分享的资源。

在上述实施例中，未对第二用户的领取资格进行任何限定，即默认第二用户可以对第一用户发生指定行为并领取第一用户分享的资源。当然，根据应用需求的不同，也可以设置一些限定条件。下面对这些限定条件进行示例性说明：

在一些实施例中，可以设定第二用户对第一用户发生指定行为的条件。基于此，在显示第一链接指向的页面之后，可以判断第二用户是否满足第一用户发生指定行为的条件；若满足，则在该页面上显示触发控件；反之，在该页面上显示第一提示信息，以提示第二用户其不满足对第一用户发生指定行为的条件。无论第二用户是否满足对第一用户发生指定行为的条件，该页面上还可以包含其它一些信息，例如指引文本信息，或一些其它控件等。例如，在第二用户不满足对第一用户发生指定行为的条件的情况下，该页面上还可以引导控件，该引导控件可把第二用户引导至第一用户的首页、第一用户的店铺、应用的活动页面或应用中特定商品的详情页面等等。在这些实施例中，将触发控件的显示与第二用户是否满足对第一用户发生指定行为的条件相关联；在满足的情况下，显示触发控件，这样第二用户通过对触发控件进行操作，从而对第一用户发生指定行为；在不满足的情况下，不显示触发控件，这样第二用户就无法对第一用户发生指定行为了。

在本实施例中，并不限定触发控件或第一提示信息在上述页面上的显示方式。例如，可以直接在上述页面上显示触发控件或第一提示信息。又例如，也可以在上述页面上显示第一悬浮窗，第一悬浮窗中包含触发控件或第一提示信息。第一悬浮窗可以是任何形状，对此不做限定。

其中，第二用户对第一用户发生指定行为的条件可根据应用需求灵活设定。例如，接续于前述对第一用户进行资源分享的资格进行限定的实施例，设定一轮或多轮分享活动，每轮分享活动包含至少一个活动时段。其中，每个活动时段设置允许第二用户对不同第一用户发生指定行为的次数上限值，和/或，在每个活动时段设置仅允许同一第二用户对同一第一用户发生一次指定行为，和/或，每一轮分享活动结束后第二用户不再具备。

基于上述，判断第二用户是否满足对第一用户发生指定行为的条件，包括以下至少一种判断操作：

判断第二用户在当前活动时段内对不同第一用户发生指定行为的次数是否已经达到上限；

判断第一用户参与的本轮分享活动是否已经结束；

判断第二用户在当前活动时段内是否已经对第一用户发生过指定行为；

若任一判断操作的判断结果为是，确定第二用户不满足对第一用户发生指定行为的条件；若至少一种判断操作的判断结果均为否，确定第二用户满足对第一用户发生指定行为的条件。

在一可选实施例中，若第二用户对页面上触发控件进行操作，第二终端设备可与服务端设备相互配合，确定第二用户对第一用户发生指定行为，该过程包括：第二终端设备响应第二用户对页面上触发控件的操作，向服务端发送信息处理请求，以请求服务端设备为第一用户进行与指定行为相关的处理操作，并在处理成功之后向第二终端设备返回处理成功消息；对第二终端设备来说，若接收到服务端返回的处理成功消息，确定第二用户对第一用户发生指定行为。

其中，根据指定行为的不同，服务端设备为第一用户进行与指定行为相关的处理操作也会有所不同。例如，若指定行为是点赞行为，则服务端设备可接收第二终端设备发送的点赞处理请求，根据该处理请求，可增加第一用户的点赞数量，并向第一终端设备同步更新后的第一用户的点赞数量，在同步操作结束后，可以向第二终端设备返回处理成功消息。需要说明的是，这里的点赞处理过程仅为示例性说明，并不限于此。

在上述实施例中，并未对“为第二用户获取第一用户分享的资源”进行条件限定。当然，根据应用需求，可设置合理或适当的资源获取条件。例如，第一用户分享的资源具有一定有效期，这里的有效期是指资源被获取的有效期，例如可以是24小时、3天等，如果有效期结束，则无法为第二用户获取第一用户分享的资源。又例如，第一用户分享的资源是否还有剩余，如果没有剩余，则无法为第二用户获取第一用户分享的资源。在设置资源获取条件的情况下，在为第二用户获取第一用户分享的资源之前，可以判断第一用户分享的资源是否处于可获取状态；若第一用户分享的资源处于可获取状态，为第二用户获取第一用户分享的资源。

可选地，判断第一用户分享的资源是否处于可获取状态包括以下至少一种判断操作：

判断第一用户分享的资源是否已过期；

判断第一用户分享的资源是否已经没有剩余；

若任一判断操作的判断结果为是，确定第一用户分享的资源处于不可获取状态；若至少一种判断操作的判断结果均为否，确定第一用户分享的资源仍处于可获取状态。

以第一用户分享的资源的有效期是24小时为例，则判断第一用户分享的资源是否已过期，是指判断第一用户分享的资源被分享出去的时间长度是否超过24小时；如果超过24小时，确定第一用户分享的资源已经过期；反之，确定第一用户分享的资源尚未过期。

可选地，若第一用户分享的资源已过期，对于已经过期的资源可以回退到第一用户的资源账户中，或者，对于已经过期的资源，也可以视为作废或者被冻结。

对第一用户来说，其分享的资源数量可以是一个或多个。若第一用户分享的资源是一个，意味着第一用户分享的资源可被一个用户获取，则判断第一用户分享的资源是否已经没有剩余，是指判断是否已经有用户获取了第一用户分享的资源；若是，确定第一用户分享的资源已经没有剩余；反之，确定第一用户分享的资源尚有剩余。若第一用户分享的资源是多个，意味着第一用户分享的资源可被多个用户获取，则判断第一用户分享的资源是否已经没有剩余，是指判断第一用户分享的每一个资源是否均已经有用户获取了；若是，确定第一用户分享的资源已经没有剩余；反之，确定第一用户分享的资源尚有剩余。

进一步，在第一用户分享的资源仍处于不可获取状态的情况下，可以在上述页面上显示第二提示信息，一方面提示第二用户已经无法获取第一用户分享的资源，另一方面提示第二用户是否继续对第一用户发生指定行为。在第一用户分享的资源处于不可获取状态的情况下，若第二用户确定继续对第一用户发生指定行为，则可以对页面上的触发控件进行操作，第二终端设备可响应第二用户对触发控件的操作，确定第二用户对第一用户发生指定行为，但此时不会为第二用户获取第一用户分享的资源。

进一步，在第一用户分享的资源仍处于可获取状态的情况下，同样可以在第一链接指向的页面上显示第三提示信息，用以提示可以为第二用户获取第一用户分享的资源。

资源获取的详细实施过程：

其中，为第二用户获取第一用户分享的资源的过程，与资源分享对应的数据处理逻辑有关。资源分享对应的数据处理逻辑不同，为第二用户获取第一用户分享的资源的过程也会有所不同。接续于前述本实施例提供的基于虚拟资源流方式实现的资源分享方案，本申请实施例提供一种为第二用户获取第一用户分享的资源的实施方式，如下所述。

在该可选实施例中，第二终端设备向服务端设备发送资源获取请求，以供服务端设备确定第二用户能否从第一用户分享的资源中获取到资源并在能够获取到的情况下返回第二用户获取到的目标资源分量；接收服务端设备返回的第二用户获取到的目标资源分量，并在页面上显示目标资源分量，以供第二用户了解其获取到的资源量。

对服务端设备来说，可接收第二终端设备发送的资源获取请求；根据资源获取请求判断N个可获取的资源分量是否还有剩余；若是，从剩余的资源分量中，确定第二用户获取到的目标资源分量，并向第二终端设备返回所述目标资源分量；以及记录资源获取流水信息，该资源获取流水信息包含第二用户获取到目标资源分量的信息。其中，第二用户获取到目标资源分量的信息包括但不限于：第二用户的标识、目标资源分量、获取时间等。

可选地，服务端设备可以记录N个可获取的资源分量的生成顺序，按照该生成顺序向第二用户分配可获取的目标资源分量。除此之外，服务端设备也可以按照随机分配方式，向第二用户分配可获取的目标资源分量。

在上述资源获取过程中，第二用户分配到的仅是目标资源分量，该目标资源分量对应的资源依旧存在中间账户中，并未从中间账户转入第二用户的资源账户中，形成一种虚拟资源流向。

获取资源后的数据处理过程：

在为第二用户获取到第一用户分享的资源之后，还涉及第二用户对所获取资源的处理过程。其中，根据应用需求的不同，第二用户对所获取的资源的处理过程也可以不同。例如，在一些应用场景中，允许第二用户将所获取的资源提现，即第二用户可以将所获取的资源从中间账户转入自己的资源账户中。又例如，在一些应用场景中，不允许第二用户将所获取的资源提现，但允许第二用户对所获取的资源进行转移处理，即第二用户可以将所获取的资源从中间账户中转移到第三方资源账户中。其中，第三方资源账户不同于第一用户的资源账户、第二用户的资源账户，也不同于中间账户。

在不同应用场景中，对资源转移处理的解释会有所不同。例如，在一些场景中，第二用户发起的资源转移行为是指购买行为，则可以将所获取的资源从中间账户转入卖家或商家的资源账户。又例如，在一些场景中，第二用户发起的资源转移行为是指馈赠行为，则可以将所获取的资源从中间账户转入被馈赠方的资源账户。

基于上述分析，在显示目标资源分量之后，第二终端设备还可以检测第二用户是否在第一应用中发起资源转移行为，在检测到第二用户在第一应用中发起资源转移行为的情况下，可确定资源转移行为涉及的第三方资源账户；然后，向服务端发送资源转移请求，以请求服务端将所述目标资源分量对应的资源从中间账户转移到第三方资源账户中。

相应地，服务端设备还可以接收第二终端设备发送的资源转移请求，该资源转移请求包括资源转移行为涉及的第三方资源账户；根据之前记录的资源获取流水信息，将目标资源分量对应的资源从中间账户转移到第三方资源账户。

需要说明的是，可以在一次资源转移行为下，将目标资源分量对应的资源全部从中间账户转移到第三方资源账户。或者，也可以是在多次资源转移行为下，分多次将目标资源分量对应的资源全部从中间账户转移到相应第三方资源账户，每次将部分资源从中间账户转移到相应第三方资源账户。不同资源转移行为涉及的第三方资源账户可以相同，也可以不同。

进一步，在本申请实施例中，还可以为第二用户获取到的第一用户分享的资源设置有效期。这里的有效期是指第二用户已获取的资源被转移(或使用)的有效期，例如48小时、7天、一个月或一年等。第二用户需要在有效期内，对该资源进行转移处理。基于此，服务端设备在接收第二终端设备的资源转移请求之前，还可以判断目标资源分量对应的资源的有效期是否结束；若结束，可以将目标资源分量对应的资源从中间账户退回至第一用户的资源账户。若未结束，可等待第二用户对该资源进行转移处理。

进一步，在将目标资源分量对应的资源从中间账户转移到第三方资源账户之后，服务端设备还需要记录资源转移流水信息，该资源转移流水信息包括目标资源分量对应的资源从中间账户转移到第三方资源账户的相关信息。这里的相关信息包括但不限于：第三方资源账户、被转移资源量、资源转移次数以及每次资源转移的转移时间等等。

在本申请实施例中，第一用户通过邀请第二用户到应用中对其发生指定行为来为应用拉取用户，在第一用户请求第二用户到应用中对其发生指定行为的过程中嵌入资源分享机制，通过资源分享机制可增加第二用户参与的积极性，提升第二用户的参与度和参与效果，有利于快速提升应用的用户回流量。

场景化实施例：

为了便于理解本申请技术方案，在下面场景实施例中以某购物类应用为例展开说明。

在该购物类应用中，为了刺激第一用户为应用拉取用户，开启了互动(PK)活动。在该互动活动中，参与用户需要向其它用户分享点赞页面来拉取其它用户为其点赞，在不同参与用户之间就点赞量进行比赛(简称为PK点赞量)，比赛或PK获胜的一方可获得一定奖励。例如，PK获胜的一方可以提升用户等级，用户等级越高，购物享受的优惠越高。又例如，PK获胜的一方可以获得指定活动期间的满减优惠券、免单优惠券或折扣券等。其中，每个参与用户的点赞量可体现该参与用户为应用拉取的用户量。

可选地，在上述互动活动中，可以以用户为单位，在参与用户之间PK点赞量。或者，在上述互动活动中，参与互动活动的用户之间可以组队，以队为单位，在不同组队之间PK点赞量，参与PK的至少为两队，每一队至少包括一个用户。关于用户之间如何组队对此不做限定。参与PK的至少两队中，各队包含相同用户数量。每一队中的每个用户均需要分享点赞页面拉取其它用户为其点赞，该队中所有用户的点赞量之和作为该队的点赞量。对所有参与互动活动的用户来说，其通过分享点赞页面拉取其它用户为其点赞的方式相同或类似，故在本场景实施例中，仍以第一用户拉取第二用户为其点赞为例展开说明。第一用户是参与互动活动中的任一用户。

为了方便第一用户快速、高效地拉取更多用户为其点赞，购物类应用为用户提供了一种红包点赞的机制，即在分享点赞过程中嵌入红包机制。其中，图2与图3a-图3e，描述了第一用户通过发红包向第二用户分享点赞的过程。图4与图5a-图5d，描述了第二用户在领红包过程中为第一用户点赞的过程。

参见图2所示基于发红包的分享点赞流程：

步骤21：第一用户进入活动页面，该活动页面上显示有发红包控件。本实施例并不限定发红包控件的实现形式，例如可以是一个按钮，或者是一个指向红包充值页面的快捷键，或者是一个指向红包充值页面的悬浮窗等等。

步骤22：判断是否监听到发红包控件的触发操作；若是，表示第一用户选择发红包，进入步骤23；若否，表示第一用户不发红包，可结束此次基于发红包的分享点赞操作，或进入现有分享点赞流程。对发红包控件的触发操作包括但不限于：点击、双击、悬停、触控或长按等。

步骤23：显示红包充值页面，并进入步骤24。如图3a所示，为红包充值页面的一种示意图，在图3a中，红包充值页面包括红包总金额输入区、红包个数输入区以及文本输入区。文本输入区用于供第一用户输入指引文本信息，例如“拜托拜托～快来帮我的点赞，送你一个红包”。

可选地，在互动活动中，可以设置一些第一资格限定条件，用来对第一用户发红包的行为做一些合理限定。所述第一资格限定条件包括但不限于：同一用户在互动活动期间发红包的总次数不能超过活动期间允许的次数上限值，如999次；在互动活动持续多天的情况下，同一用户在每天发红包的总次数不能超过每天允许的次数上限值，如99次；同一用户在活动期间发红包的总金额不能超过活动期间允许的金额上限值，如1000元。

基于上述，在步骤24中，根据预先设定的第一资格限定条件，判断第一用户是否有资格发红包；若是，进入步骤26；若否，进入步骤25。

步骤25：在红包充值页面上显示第一用户无资格发红包的原因信息，并结束此次基于发红包的点赞操作。以第一用户在互动活动期间发红包的总次数达到活动期间允许的次数上限值999为例，如图3b所示，可在红包充值页面上显示“够壕！您发红包次数累计已达上限999次”。

步骤26：响应红包充值页面上的输入操作，获取第一用户输入的总金额和红包个数，并进入步骤27。基于图3a所示红包充值页面，输入的总金额和红包个数后的红包充值页面的一种示意图如图3c所示。在图3c中，以红包总金额是21.83元，红包个数为34个进行示例性说明。

可选地，还可以设置一些红包限定条件，用于对发出的红包进行限定，进而保证发出的红包更加合理。红包限定条件包括但不限于：限定发红包的总金额不能少于设定的金额最小值，如0.1元；限定发红包的个数不能少于设定的个数最小值，如1个；等等。基于此，在步骤26中，还可以判断第一用户输入的总金额是否小于设定的金额最小值，以及判断第一用户输入的红包个数是否小于设定的个数最小值；如果均为否，则可以获取第一用户输入的总金额和红包个数；反之，可以提示第一用户重新输入。

步骤27：响应第一用户对红包充值页面上的充值控件的触发操作，向服务端发送充值请求，以配合服务端进行充值操作，并进入步骤28。

其中，第一终端设备配合服务端进行充值操作，包括：服务端向第一终端设备返回支付页面，该支付页面包括互动活动的相关信息、支付账号、支付金额(即红包总金额)、支付时间等信息；第一用户输入支付密码确认支付后，服务端会总第一用户绑定的资源账户中转移红包总金额对应的资金到中间账户，并会根据红包总金额和红包个数生成发红包的第一链接，将该第一链接返回给第一终端设备。关于服务端生成第一链接的流程可参见图6a所示实施例。

步骤28：接收服务端在充值成功后返回的第一链接，并借助于购物类应用支持的分享功能将该第一链接分享给第二用户。第一链接可以是淘口令，但并不限于此。在图3d中，以红包形态的淘口令为例对第一链接进行图示，而且在红包形态的淘口令上显示有“第一用户XXX的点赞红包”的指引文本信息，这里的指引文本信息仅为示例。另外，在图3d中示出可以采用但不限于：洋淘圈、朋友圈、支付宝、钉钉等分享方式。

在此说明，第一用户分享的点赞红包可以是随机红包，也可以是常规红包。随机红包是指不同领取用户领取到的红包金额可能不同，是随机分配的。常规红包是指不同领取用户领取到的红包金额是相同的，都是固定金额的。在本实施例中，对点赞红包的类型不做限定。

步骤29：第一用户再次进入活动页面，该活动页面上显示有发红包控件。

步骤30：判断是否监听到对发红包控件的触发操作；若是，进入步骤31；若否，结束此次基于发红包的分享点赞操作。

步骤31：显示红包充值页面，该红包充值页面包括红包列表区域，在该区域中显示有第一用户已经分享的各红包的信息，这些信息包括但不限于：每次分享红包的时间、每个分享的红包的总金额、每次分享的红包是否已被领完、每次分享的红包的总个数，以及在红包未被领完的情况下对应的分享控件。如图3e所示为一种包含红包列表区域的红包充值页面的示意图。

步骤32：响应对红包列表区域中分享控件的触发操作，再次分享未被领取完的红包。

可选地，如图3e所示，红包列表区域包括至少一个子区域，每个子区域显示第一用户分享过的一个红包信息。第一用户还可以点击相应红包对应的子区域，进入该红包对应的领取详情页。对第一终端设备来说，响应第一用户对某个子区域的点击操作，显示该子区域对应红包的领取详情页。

参见图4所示基于领红包的点赞流程：

步骤41：显示第一链接，第一链接是第一用户分享的。

步骤42：响应第二用户对第一链接的触发操作，显示第一链接对应的活动页面。

可选地，在互动活动中，可以设置一些第二资格限定条件，用来对第二用户领红包的行为做一些合理限定。所述第二资格限定条件包括但不限于：互动活动结束后不允许点赞；在互动活动持续多天的情况下，同一用户在每天点赞的总次数不能超过每天允许的次数上限值，如10次；在互动活动期间，对同一个被点赞用户，每个点赞用户每天只能为该被点赞用户点赞一次；等等。

基于上述，在步骤43中，判断第二用户是否具有领红包点赞的资格；若是，进入步骤45；若否，进入步骤44。

步骤44：在活动页面上以悬浮窗的方式显示红包页面，在红包页面上显示提示信息，以提示第二用户不具备参与点赞领红包的资格。该情况下的页面状态示意图如图5a所示。在图5a中，以第二用户当天点赞次数已用光为例进行图示，其它情况类似。

进一步，在图5a所示页面上，还可以显示其它界面元素，例如“去我的互动主页面”等字样的控件，第二用户点击该控件可进入第一用户的互动主页面。本申请实施例并不对互动主页面的内容和形式进行限定，例如可以是具有趣味性或娱乐性的页面，例如可以是能够饲养虚拟动物的虚拟农场页面等。

步骤45：判断第一用户分享的红包是否处于可领取状态；若是，进入步骤46；若否，进入步骤47。

可选地，可以判断红包是否过期；若过期，确定红包处于不可领取状态。或者，判断红包是否已经被领取完，即是否还有余额；若已被领取完，即没有余额，确定红包处于不可领取状态。当然，上述两种操作可结合在一起使用。

步骤46：在活动页面上以悬浮窗的方式显示红包页面，在红包页面上显示点赞控件，并进入步骤48。该情况下的页面状态示意图如图5b所示。可选地，红包页面上还可以显示一些指引文本信息，如图5b显示的“赶紧点赞领红包吧”。

步骤47：在活动页面上以悬浮窗的方式显示红包页面，在红包页面上显示点赞控件，并显示不可领取红包是否继续点赞的提示信息，进入步骤48。该情况下的页面状态示意图如图5c所示。在图5c中，以红包过期的情况为进行图示，图5c中显示的提示信息为“红包过期，下次早点来吆”。例如，红包领取有效期可以是24小时、3天等。

步骤48：判断是否监听到对点赞控件的触发操作；若是，表示第二用户对第一用户点赞，并领红包，进入步骤49；若否，结束此次基于领红包的点赞操作。

步骤49：向服务端发送点赞请求，以配合服务端完成对第一用户的点赞操作。进一步，若从步骤46跳转至步骤48，该方法还包括步骤50。

步骤50：向服务端发送领取请求，以配合服务端完成领红包操作。其中，第二用户为第一用成功点赞，且成功领取红包的页面示意图如图5d所示。

在此说明，上述图3a-3e以及图5a-5d均为页面状态示意图，在这些附图中主要体现了与本申请技术方案相关的界面元素，本领域技术人员可以理解根据应用场景的不同，这些附图所示页面中可以包含其它一些界面元素，例如图片、文本、小视频等等，对此不做限定。

在上述发红包过程中，服务端需要配合第一终端设备完成发红包对应的后台数据处理流程。同理，在上述领红包过程中，服务端还需要配合第二终端设备完成领红包对应的后台数据处理流程。在本申请实施例中，并不限定服务端的设备实现形态，可以是一台服务器，也可以是服务器阵列，还可以是一个服务***。以本实施例的服务端包括：负责互动活动的第一服务节点和负责支付管理的第二服务节点为例，则一种发红包对应的后台数据处理流程如图6a，一种领红包对应的后台数据处理流程如图6b所示。

参见图6a，发红包对应的后台数据处理流程，包括：

61a、第一服务节点接收第一终端设备发送的充值请求，包括红包总金额和红包个数等信息。

62a、第一服务节点根据充值请求向第二服务节点发送发红包指令，包括红包总金额和红包个数等信息。

63a、第二服务节点根据发红包指令，创建支付订单和创建支付链接。

64a、第二服务节点将支付订单和支付链接通过第一服务节点转发给第一终端设备。

65a、第一服务节点接收第一终端设备发送的红包支付请求。

66a、第一服务节点将红包支付请求转发给第二服务节点。

67a、第二服务节点根据红包支付请求，从第一用户的资源账户中转移红包总金额对应的资金到中间账户。

68a、第二服务节点将红包总金额拆分为M个红包金额，M是红包个数，并记录M个红包金额以及生成顺序，以供第二用户领取。M个红包金额可以相同，也可以不相同。例如，第二服务节点可以采用一定随机算法将红包总金额拆分为M个随机红包金额，并不限于此。

69a、第二服务节点生成分享红包所需的第一链接，该第一链接指向活动页面，并与M个红包金额关联。

70a、第二服务节点通过第一服务节点将第一链接返回给第一终端设备，以供第一终端设备将第一链接分享给第二用户。

参见图6b，领红包对应的后台数据处理流程，包括：

61b、第二终端设备向第一服务节点发送领取请求，以请求领取红包。

62b、第一服务节点将领取请求转发给第二服务节点。

63b、第二服务节点根据领取请求，判断M个红包金额是否还有剩余；在之前生成的M个红包金额有剩余的情况下，按照红包金额生成时间，将一个红包金额分配给第二用户，记录一笔红包领取流水。在该过程中，并不会产生实际的资金流水。

其中，第二用户每领取一个红包，第二服务节点会为其记录一笔红包领取流水。若第二用户领取了多个红包，会有多笔红包领取流水。

64b、第二服务节点通过第一服务节点将第二用户领取到的红包金额返回给第二终端设备，以供第二终端设备显示给第二用户。

第二用户在领取到红包之后，可以使用红包。在本实施例中，对分享点赞中的红包做特殊规定，这种红包不可体现，只能用于在指定活动期间进行消费。

65b、第二终端设备向第一服务节点发送购物支付请求，该购物支付请求携带有商家的资源账户以及待支付金额等信息。

66b、第一服务节点将购物支付请求转发给第二服务节点。

67b、第二服务节点查看第二用户的红包领取流水，根据所有红包领取流水中的红包金额和待支付金额，确定出可使用的红包金额。

例如，若所有红包领取流水中的红包金额之和小于待支付金额，可以将所有红包领取流水中的红包金额均作为可使用的红包金额；反之，选择部分红包领取流水中的红包金额(这些红包金额之和大于或等于待支付金额)，作为可使用的红包金额。

本实施例中，第二用户领取到的红包金额可以分多次使用，每次使用部分红包金额，直到红包金额使用完，或者红包使用有效期结束为止。可选地，每个被领取的红包金额都有一个使用有效期，该使用有效期可以是自领取之日起一个月、三个月或一年，也可以是指定或特定活动期间，等等。

68b、第二服务节点将可使用的红包金额从中间账户转移到商家的资源账户中，并记录红包使用流水。这里的红包使用流水可以是一笔，也可以是多笔，可根据使用了几个红包金额而定。

可选地，若待支付金额大于所有红包金额之和，第二服务节点还会从第二用户的资源账户中转移一部分资金到商家的资源账户中。

69b、第二服务节点通过第一服务节点向第二终端设备返回支付结果。

需要说明的是，上述流程仅为示例性说明，并不限于此。

本申请实施例的技术方案主要涉及以下两个过程：第一用户进行资源分享的过程，以及第二用户获取第一用户分享的资源的过程，但并不限于这两个过程。例如，本申请技术方案还会涉及第二用户获取资源后的资源转移流程等。以下结合附图，将对本申请技术方案涉及的两个主要过程以及其它过程进行详细说明。

图7a为本申请示例性实施例提供的一种数据处理方法的流程示意图。本实施例主要从第一用户角度，描述了资源分享过程。如图7a所示，该方法包括：

71a、根据第一用户的分享请求，显示分享页面；

72a、基于分享页面，获取第一用户要分享的资源信息；

73a、基于资源信息生成资源分享所需的第一链接，第一链接指向的页面包含触发控件，触发控件与指定行为对应；

74a、将上述第一链接发送给第二用户，以使第二用户通过触发控件对第一用户发生指定行为并获取第一用户分享的资源。

在本实施例中，分享页面是第一用户与第一终端设备之间的交互界面，第一终端设备可基于该分享页面获取第一用户要分享的资源信息。其中，第一用户要分享的资源信息包括但不限于：第一用户要分享的资源总量和资源个数等信息。

在一可选实施例中，分享页面上默认携带有第一用户要分享的资源信息。基于此，步骤72a的一种实施方式包括：直接获取分享页面上默认携带的第一用户要分享的资源信息，例如资源总量和资源个数等。

在另一可选实施中，分享页面支持输入操作。基于此，步骤72a的另一种实施方式包括：响应第一用户在分享页面上的输入操作，获取第一用户输入的资源总量和资源个数作为资源信息。

基于上述，步骤73a，即基于该资源信息生成资源分享所需的第一链接的一种实施方式包括：根据资源总量，从第一用户的资源账户中转出相应资源到中间账户；根据资源个数，将资源总量拆分为N个可获取的资源分量，N表示资源个数，是正整数；根据触发控件和N个可获取的资源分量，生成第一链接。

其中，N个可获取的资源分量可以相同。例如，可以利用资源总量除以资源个数N，得到N个相同的资源分量。当然，N个资源分量也可以不同，这里的“不同”可以是N个资源分量完全不相同，也可以是N个资源分量中有部分不相同。例如，可以根据资源总量和资源个数N，随机生成N个资源分量。

在本实施例中，第一链接指向的页面包含触发控件，该触发控件与指定行为对应。换句话说，一旦该触发控件被触发，“对第一用户发生指定行为的操作”就会被执行。另外，第一链接指向的页面还具有让第二用户获取第一用户分享的资源功能，可称之为资源领取页面，因此，触发控件还可以触发“为第二用户获取第一用户分享的资源的操作”。

在本实施例中，并不对“指定行为”进行限定，是拉人机制中要求或设定的行为，可根据应用场景灵活设定。举例说明，指定行为可以是点赞行为、入团行为或加血行为，也可以是评论行为、砍价行为、浏览指定商品的行为或代付行为，等等。

进一步，第一用户要分享的资源信息除了包括第一用户要分享的资源总量和资源个数之外，还可以包括指引文本信息。其中，指引文本信息体现资源分享与发生指定行为之间的关联关系。基于此，在本申请另一些实施例中，基于分享页面，获取第一用户要分享的资源信息还包括：获取第一用户输入的指引文本信息作为资源信息。相应地，上述根据触发控件和N个可获取的资源分量，生成第一链接，包括：根据触发控件、N个可获取的资源分量以及指引文本信息，生成第一链接。在该实施例中，第一链接指向的页面除了包含触发控件之外，还包括指引文本信息。另外，第一链接也可以包含指引文本信息。

在一些可选实施例中，为了让资源分享更加合理，可以设置一些资源分享要求。例如，可以设置资源总量要求，用来将资源总量限定在合理范围，例如不能少于设定的下限值，如0.1，不能大于设定的上限值，如999。还可以设置资源个数要求，用来将资源个数限定在合理范围内，例如不能少于设定的下限值，如1个，不能大于设定的上限值，如99个。进一步，还可以设置用语规范，用来规范指引文本信息，例如不允许出现不文明用词、敏感字词等，不能超过最大字数限制等。这些要求可根据应用需求灵活设定。

基于上述，在步骤72a，即基于分享页面，获取第一用户要分享的资源信息的过程中，还可以执行以下判断操作：

判断第一用户输入的资源总量是否满足设定的资源总量要求；

判断第一用户输入的资源个数是否满足设定的资源个数要求；

判断第一用户输入的指引文本信息是否符合设定的用语规范；

若上述判断操作的判断结果均为是，则获取第一用户输入的资源总量、资源个数和指引文本信息作为资源信息。

在一些可选实施例中，也可以根据应用场景，设置一些规则对第一用户进行资源分享的次数和时间等进行合理限定。基于此，在步骤72a，即基于分享页面，获取第一用户要分享的资源信息之前，本实施例方法还可以包括：判断第一用户在本轮分享活动中分享资源的总次数是否已经达到本轮分享活动允许的次数上限，每轮分享活动包括至少一个活动时段；判断第一用户在当前活动时段内分享资源的次数是否已经达到当前活动时段允许的次数上限；若至少一种判断操作的判断结果均为否，则允许第一用户在分享页面上执行输入操作。

在一些可选实施例中，第一用户分享第一链接之后，还可以再次发起分享请求。此时，第一用户之前已经分享过的资源可能会有剩余。鉴于此，在步骤74a，即将第一链接发送给第二用户之后，该方法还包括：根据第一用户再次发起的分享请求，显示分享页面，该分享页面显示有第一用户已经分享的资源的信息以及分享控件；响应于第一用户对所述分享控件的触发操作，继续将第一链接发送给第三用户，所述第三用户是任何未获取过第一用户分享的资源的用户。第三用户可以包括不同于第二用户的新用户，也可以包括并未获取第一用户分享的资源的第二用户。在第一用户再次发出分享请求时，若第一用户之前已分享的资源还有剩余，分享页面上可显示分享控件。这样第一用户可以点击该分享控件，继续对尚有剩余的资源进行分享。

进一步，在一些可选实施例中，本实施例的方法还包括：接收第二用户的资源获取请求；判断上述N个可获取的资源分量是否还有剩余；若是，从剩余的资源分量中，确定第二用户获取到的目标资源分量，并向第二用户返回目标资源分量；以及记录资源获取流水信息，资源获取流水信息包含第二用户获取到目标资源分量的信息。其中，第二用户获取到目标资源分量的信息包括但不限于：第二用户的标识、目标资源分量、获取时间等。

在一些可选实施例中，本实施例的方法还包括：接收第二用户的资源转移请求，该资源转移请求包括资源转移行为涉及的第三方资源账户；根据资源获取流水信息，将目标资源分量对应的资源从中间账户转移到第三方资源账户。

进一步可选地，在接收第二用户的资源转移请求之前，本实施例方法还包括：判断目标资源分量对应的资源的有效期是否结束；若结束，将目标资源分量对应的资源从中间账户退回至第一用户的资源账户。

进一步可选地，在将目标资源分量对应的资源从中间账户转移到第三方资源账户之后，本实施例方法还包括：记录资源转移流水信息，该资源转移流水信息包括目标资源分量对应的资源从中间账户转移到第三方资源账户的相关信息。

需要说明的是，上述与资源获取请求相关的操作以及与资源转移请求相关的操作，可由第一终端设备完成，也可以由服务端设备执行，对此不做限定。

在本实施例中，第一用户通过邀请第二用户到应用中对其发生指定行为来为应用拉取用户，在第一用户请求第二用户到应用中对其发生指定行为的过程中嵌入资源分享机制，通过资源分享机制可增加第二用户参与的积极性，提升第二用户的参与度和参与效果，有利于快速提升应用的用户回流量。

图7b为本申请示例性实施例提供的另一种数据处理方法的流程示意图。本实施例主要从第二用户角度，描述了资源获取过程。如图7b所示，该方法包括：

71b、显示第一链接指向的页面，第一链接是第一用户分享的；

72b、响应第二用户对页面上触发控件的操作，确定第二用户对第一用户发生指定行为；

73b、为第二用户获取第一用户分享的资源；其中，触发控件与指定行为对应。

在本实施例中，并不对“指定行为”进行限定，指定行为包括但不限于以下至少一种：助力行为、浏览行为、代付行为和评论行为。同理，本实施例也不对“第一链接”的实现形式进行限定，例如第一链接为淘口令，一维码，二维码或URL链接等。

相应地，根据应用场景的不同，第一链接指向的页面也会有所不同。举例说明：上述页面可以为PK活动中的PK页面，或者，为砍价活动的砍价页面，或者，团购活动中的商品详情页面，或者，资源领取活动中的资源领取页面，等等。

在一些可选实施例中，中，在步骤72b，即响应第二用户对所述页面上触发控件的操作之前，本实施例方法还包括：判断第二用户是否满足第一用户发生指定行为的条件；若满足，则在该页面上显示触发控件；反之，在该页面上显示第一提示信息，以提示第二用户其不满足对第一用户发生指定行为的条件。

在本实施例中，并不限定触发控件或第一提示信息在上述页面上的显示方式。例如，可以直接在上述页面上显示触发控件或第一提示信息。又例如，也可以在上述页面上显示第一悬浮窗，第一悬浮窗中包含触发控件或第一提示信息。第一悬浮窗可以是任何形状，对此不做限定。

可选地，上述判断第二用户是否满足对第一用户发生指定行为的条件包括：执行以下至少一种判断操作：判断第二用户在当前活动时段内对第一用户发生指定行为的次数是否已经达到上限；判断第一用户参与的本轮分享活动是否已经结束，每轮分享活动包括至少一个活动时段；判断第二用户在当前活动时段内是否已经对第一用户发生过指定行为；若任一判断操作的判断结果为是，确定第二用户不满足对第一用户发生指定行为的条件；若至少一种判断操作的判断结果均为否，确定第二用户满足对第一用户发生指定行为的条件。

在一可选实施例中，步骤72b，即响应第二用户对页面上触发控件的操作，确定第二用户对第一用户发生指定行为包括：响应第二用户对页面上触发控件的操作，向服务端发送信息处理请求，以请求服务端设备为第一用户进行与指定行为相关的处理操作；对服务端设备来说，可根据信息处理请求，对第一用户进行与指定行为相关的处理操作，并在处理成功之后向第二终端设备返回处理成功消息；对第二终端设备来说，若接收到服务端返回的处理成功消息，确定第二用户对第一用户发生指定行为。

在一些可选实施例中，根据应用需求，可设置合理或适当的资源获取条件。在设置资源获取条件的情况下，在为第二用户获取第一用户分享的资源之前，可以判断第一用户分享的资源是否处于可获取状态；若第一用户分享的资源处于可获取状态，为第二用户获取第一用户分享的资源。

可选地，判断第一用户分享的资源是否处于可获取状态包括以下至少一种判断操作：判断第一用户分享的资源是否已过期；判断第一用户分享的资源是否已经全部被领取；若任一判断操作的判断结果为是，确定第一用户分享的资源处于不可获取状态；若至少一种判断操作的判断结果均为否，确定第一用户分享的资源仍处于可获取状态。

进一步，在第一用户分享的资源仍处于不可获取状态的情况下，可以在上述页面上显示第二提示信息，一方面提示第二用户已经无法获取第一用户分享的资源，另一方面提示第二用户是否继续对第一用户发生指定行为。在第一用户分享的资源处于不可获取状态的情况下，若第二用户确定继续对第一用户发生指定行为，则可以对页面上的触发控件进行操作，第二终端设备可响应第二用户对触发控件的操作，确定第二用户对第一用户发生指定行为，但此时不会为第二用户获取第一用户分享的资源。

在一些可选实施例中，步骤73b为第二用户获取第一用户分享的资源，包括：第二终端设备向服务端设备发送资源获取请求，以供服务端设备确定第二用户能否从第一用户分享的资源中获取到资源并在能够获取到的情况下返回第二用户获取到的目标资源分量；接收服务端设备返回的第二用户获取到的目标资源分量，并在页面上显示目标资源分量，以供第二用户了解其获取到的资源量。

进一步可选地，本实施例的方法还包括：在上述页面上，显示查看控件，以及响应第二用户对查看控件的触发操作，显示第一用户的资源分享详情。在该可选实施例中，并不限定目标资源分量以及查看控件在上述页面上的显示方式。其中，在上述页面上，显示目标资源分量以及查看控件的一种可选方式包括：在页面上显示第二悬浮窗，第二悬浮窗中包含目标资源分量以及查看控件，

在一可选实施例中，第一用户分享的资源被存储在中间账户中。第二用户分配到的仅是目标资源分量，该目标资源分量对应的资源依旧存在中间账户中，并未从中间账户转入第二用户的资源账户中，形成一种虚拟资源流向。

本实施例的方法在显示目标资源分量之后，还包括：检测第二用户是否在第一应用中发起资源转移行为；若检测到第二用户在第一应用中发起资源转移行为，确定资源转移行为涉及的第三方资源账户，第一应用是第一链接指向的页面所属的应用；向服务端发送资源转移请求，以请求服务端将目标资源分量对应的资源从中间账户转移到第三方资源账户中。在不同应用场景中，对资源转移处理的解释会有所不同。例如，在一些场景中，第二用户发起的资源转移行为是指购买行为，则可以将所获取的资源从中间账户转入卖家或商家的资源账户。又例如，在一些场景中，第二用户发起的资源转移行为是指馈赠行为，则可以将所获取的资源从中间账户转入被馈赠方的资源账户。

在本实施例中，第一用户通过邀请第二用户到应用中对其发生指定行为来为应用拉取用户，在第一用户请求第二用户到应用中对其发生指定行为的过程中嵌入资源分享机制，通过资源分享机制增加了第二用户参与的积极性，提升第二用户的参与度和参与效果，有利于快速提升应用的用户回流量。

上述数据处理方法可应用于各种场景，在不同应用场景中，指定行为和资源等信息可被具体化。下面以助力场景为例对本申请技术方案进行描述。

第一用户需要其它用户为其助力时，可以发出助力请求。在该助力过程中，可嵌入红包分享机制。对第一终端设备来说，可根据第一用户的助力请求，显示红包分享页面；基于红包分享页面，获取第一用户要分享的红包信息；红包信息包括但不限于：红包总金额和红包总个数。进而，基于红包信息生成分享红包所需的第一链接，第一链接指向的红包领取页面包含助力控件。之后，将第一链接发送给第二用户，以供第二用户通过该助力控件为第一用户助力并获取第一用户分享的红包。

对第二用户来说，其终端设备(即第二终端设备)可接收第一用户分享的第一链接，并显示第一用户分享的第一链接。其中，第一用户分享的第一链接可由第一终端设备发送给第二终端设备。第二用户看到第一用户分享的第一链接之后，可以点击该第一链接。第二终端设备可响应第二用户对第一链接的点击操作，显示第一链接指向的红包领取页面，在该红包领取页面上显示有助力控件。第二用户通过对该助力控件进行操作，可发起对第一用户进行助力的行为。第二终端设备响应第二用户对该助力控件的操作，对第一用户进行助力，并为第二用户领取第一用户分享的红包。

关于上述助力方法的详细实施过程以及相关说明，可参见前述实施例，在此不再赘述。

在本申请上述实施例中，第二用户可点击第一用户分享的第一链接，进入第一链接指向的页面，并通过该页面上的点赞控件为第一用户点赞并领取第一用户分享的红包。需要说明的是，第二用户为第一用户点赞的方式，并不限于这一种。例如，在一些应用场景中，第一用户可以将第一链接分享到具有互动功能的社交平台或应用中，例如，微博、知乎或朋友圈等。在这些应用场景中，

第二用户也可以直接在微博、知乎或朋友圈等具有互动功能的社交平台或应用中为第一用户点赞。对于第一链接隶属的第一应用，可以与微博、知乎或朋友圈等具有互动功能的社交平台或应用进行通信，获取第二用户在这些社交平台或应用中对第一用户的点赞量。其中，第一用户获得的点赞总量包含第二用户在具有互动功能的这些社交平台或应用中对第一用户的点赞量，也包括第二用户在第一应用的相应页面上对第一用户的点赞量。

另外，在本申请上述实施例中，主要以第一用户为第一应用拉取第二用户，且以“点赞和领红包相结合的示例性方案”为例，对本申请实施例提供的“资源分享和某种操作相结合的技术方案”进行了详细说明。但是，本申请实施例提供的技术方案并不限于为应用拉取用户这一种应用场景。例如，在第一应用是电商提供的购物类应用的情况下，商家也可以通过“点赞和领红包相结合的示例性方案”或类似方案为自己店铺吸引更多关注用户，或者吸引更多用户对自己或自己的商品进行评论，或者对自己的商品进行宣传，增加商品曝光率。

关注店铺+领红包或优惠券的示例性方案：

例如，商家A为了吸引更多用户关注自己的店铺，可以将发红包或优惠券与关注店铺的操作相结合方式。商家A首先确定要发放的红包或优惠券的信息，然后根据要发放的红包或优惠券的信息生成第一链接，第一链接指向商家A的店铺首页，且该第一链接中包含关注控件；然后将第一链接分享到自己的朋友圈、微博和/或知乎账号中，也可以将第一链接分享给自己的好友，或者店铺的老用户等等。看到第一链接的用户，如果触发第一链接，可进入商家A的店铺首页，在商家A的店铺首页上可弹出领红包或优惠券的浮窗，在该浮窗上包含关注控件；如果用户点击关注控件，可关注商家A的店铺，并领取商家A发放的红包或优惠券。

可选地，商家A的店铺页面上显示有发红包或优惠券的控件，商家A可以触发该发红包或优惠券控件，调出发红包或优惠券页面，在该页面上填写要发放的红包或优惠券的数量等信息，之后可点击该页面上的确认控件，向服务端提交发红包或优惠券的请求。服务端收到该请求后，可根据发红包或优惠券的信息为商家A生成第一链接，第一链接指向商家A的店铺首页，且该第一链接包含关注控件。关于分发红包或优惠券以及领取红包或优惠券的细节描述，与前述实施例相同或类似，可参见前述实施例，在此不再赘述。

发表评论+领红包或优惠券的示例性方案：

又例如，商家A为了增加商品的用户评价数，也可以采用发红包或优惠券与评价操作相结合的方式。商家A首先确定要发放的红包或优惠券的信息，然后根据要发放的红包或优惠券的信息生成第一链接，第一链接指向商家A的商品评价页面，且该第一链接中包含评价控件；然后将第一链接分享到自己的朋友圈、微博和/或知乎账号中，也可以将第一链接分享给自己的好友，或者店铺的老用户等等。看到第一链接的用户，如果触发第一链接，可进入商家A的商品评价页面，在该商品评价页面上可弹出领红包或优惠券的浮窗，在该浮窗上包含评价控件；如果用户点击评价控件，可弹出一个商品选择列表，用户可以选择需要评价的商品，用户选择要评价的商品后，可进入该商品的评价详情页，在该评价详情页上用户填写评价并提交后，可领取商家A发放的红包或优惠券。

当然，商家A也可以针对特定商品B拉取用户评价数，例如商品B可以是新上架的商品，或者是销售量比较低的商品，或者是不太受关注的商品等。对此，商家A首先确定要发放的红包或优惠券的信息，然后根据要发放的红包或优惠券的信息生成第一链接，第一链接指向商品B的评价详情页，且该第一链接中包含评价控件；然后将第一链接分享到自己的朋友圈、微博和/或知乎账号中，也可以将第一链接分享给自己的好友，或者店铺的老用户等等。看到第一链接的用户，如果触发第一链接，可进入商品B的评价详情页，在该评价详情页上可弹出领红包或优惠券的浮窗，在该浮窗上包含评价控件；如果用户点击评价控件，可弹出一个输入框，用户填写评价并提交后，可领取商家A发放的红包或优惠券。

可选地，上述评价控件也可以预先绑定预设的评价内容，用户点击评价控件之后，可直接完成评价，并领取商家A发放的红包或优惠券。进一步可选地，预设的评价内容也可以展示在浮窗中，供用户查看并确定是否进行评价。

浏览商品+领红包或优惠券的示例性方案：

又例如，商家A为对某个商品C进行宣传，增加商品C的曝光率，也可以采用发红包或优惠券与浏览操作相结合的方式。商家A首先确定要发放的红包或优惠券的信息，然后根据要发放的红包或优惠券的信息生成第一链接，第一链接指向商品C的详情页，且该第一链接中包含浏览控件；然后将第一链接分享到自己的朋友圈、微博和/或知乎账号中，也可以将第一链接分享给自己的好友，或者店铺的老用户等等。看到第一链接的用户，如果触发第一链接，可进入商品C的详情页，在该商品C的详情页上可弹出领红包或优惠券的浮窗，在该浮窗上包含浏览控件；如果用户点击浏览控件，可开始浏览商品C的详情，并可领取商家A发放的红包或优惠券。

在上述示例性实施例中，以发放红包或优惠券为例进行说明，但商家可发放的资源除了红包和优惠券之外，也可以是其它一些资源信息，例如用户在店铺中的某种用户权益，或者网络流量，或者一些视频播放APP的会员卡或电话费用等等，具体可根据应用支持的资源类型以及商家可提供的资源类型灵活设定。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤71a至步骤71d的执行主体可以为设备A；又比如，步骤71a和72a的执行主体可以为设备A，步骤73a和74a的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如71a、72a等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图8a为本申请示例性实施例提供的一种计算机设备的结构示意图。如图8a该计算机设备包括：存储器81a、处理器82a和显示器83a。

显示器83a，用于显示第一链接指向的页面，第一链接是第一用户分享的。

存储器81a，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算机设备上的操作。这些数据的示例包括用于在计算机设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

处理器82a，与存储器81a耦合，用于执行存储器81a中的计算机程序，以用于：响应第二用户对页面上触发控件的操作，确定第二用户对第一用户发生指定行为；以及为第二用户获取第一用户分享的资源；其中，触发控件与指定行为对应。

在一可选实施例中，处理器82a还用于：在响应第二用户对页面上第一控件的触发操作之前，判断第二用户是否满足对第一用户发生指定行为的条件；若满足，通过显示器83a在页面上显示触发控件；若不满足，通过显示器83a在页面上显示第一提示信息，以提示第二用户其不满足对第一用户发生指定行为的条件。

可选地，显示器83a在页面上显示触发控件或第一提示信息的一种方式，包括：在页面上显示第一悬浮窗，第一悬浮窗中包含触发控件或第一提示信息。

进一步可选地，处理器82a在判断第二用户是否满足对第一用户发生指定行为的条件时，具体用于执行以下至少一种判断操作：

判断第二用户在当前活动时段内对第一用户发生指定行为的次数是否已经达到上限；

判断第一用户参与的本轮分享活动是否已经结束，每轮分享活动包括至少一个活动时段；

判断第二用户在当前活动时段内是否已经对第一用户发生过指定行为；

若任一判断操作的判断结果为是，确定第二用户不满足对第一用户发生指定行为的条件；

若至少一种判断操作的判断结果均为否，确定第二用户满足对第一用户发生指定行为的条件。

在一可选实施例中，处理器82a在确定第二用户对第一用户发生指定行为时，具体用于：响应第二用户对触发控件的触发操作，向服务端发送信息处理请求，以请求服务端为第一用户进行与指定行为相关的处理操作；以及在接收到服务端返回的处理成功消息的情况下，确定第二用户对第一用户发生指定行为。

在一可选实施例中，处理器82a还用于：在为第二用户获取第一用户分享的资源之前，判断第一用户分享的资源是否仍处于可获取状态；若第一用户分享的资源仍处于可获取状态，为第二用户获取第一用户分享的资源。

进一步，处理器82a还用于：在第一用户分享的资源处于不可获取状态的情况下，在页面上显示第二提示信息，以提示第二用户是否继续对第一用户发生指定行为；以及在第一用户分享的资源处于不可获取状态的情况下，响应第二用户对触发控件的操作，确定第二用户对第一用户发生指定行为。

进一步，处理器82a在判断第一用户分享的资源是否仍处于可获取状态时，具体用于执行以下至少一种判断操作：

判断第一用户分享的资源是否已过期；

判断第一用户分享的资源是否已经全部被领取；

若任一判断操作的判断结果为是，确定第一用户分享的资源处于不可获取状态；

若至少一种判断操作的判断结果均为否，确定第一用户分享的资源仍处于可获取状态。

在一可选实施例中，如图8a所示，本实施例的计算机设备还包括：通信组件84a。基于此，处理器82a在为第二用户获取第一用户分享的资源时，具体用于：通过通信组件84a向服务端发送资源获取请求，以供服务端确定第二用户能否从第一用户分享的资源中获取到资源并在能够获取到的情况下返回第二用户获取到的目标资源分量；通过通信组件84a接收服务端返回的第二用户获取到的目标资源分量，并在页面上显示目标资源分量。

进一步，处理器82a还用于：通过显示器83a在第一链接指向的页面上，显示查看控件；以及响应第二用户对查看控件的触发操作，通过显示器83a显示第一用户的资源分享详情。

其中，显示器83a在显示目标资源分量以及查看控件时，具体用于：在页面上显示第二悬浮窗，第二悬浮窗中包含目标资源分量以及查看控件。

在一可选实施例中，第一用户分享的资源被存储在中间账户中。第二用户获取到的是目标资源分量，目标资源分量对应的资源依旧存储在中间账户中，并不会被转移到第二用户的资源账户中。基于此，处理器82a还用于：检测第二用户在第一应用中是否发起资源转移行为；若检测到第二用户在第一应用中发起资源转移行为，确定资源转移行为涉及的第三方资源账户，第一应用是页面所属的应用；以及通过通信组件84a向服务端发送资源转移请求，以请求服务端将目标资源分量对应的资源从中间账户转移到第三方资源账户中。

在一可选实施例中，指定行为包括以下至少一种：助力行为、浏览行为、代付行为和评论行为。

在一可选实施例中，第一链接指向的页面为PK活动中的PK页面，或者，为砍价活动的砍价页面，或者，团购活动中的商品详情页面，或者，资源领取活动中的资源领取页面。

在一可选实施例中，第一链接可以为淘口令，一维码、二维码或URL链接。

进一步，如图8a所示，该计算机设备还包括：电源组件85a、音频组件86a等其它组件。图8a中仅示意性给出部分组件，并不意味着计算机设备只包括图8a所示组件。本实施例的计算机设备可以实现为台式电脑、笔记本电脑、智能手机或IOT设备等终端设备。相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述图7b所示方法实施例中的各步骤。

图8b为本申请示例性实施例提供的另一种计算机设备的结构示意图。如图8b该计算机设备包括：存储器81b、处理器82b、显示器83b和通信组件84b。

显示器83b，用于根据第一用户的分享请求，显示分享页面。

存储器81b，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算机设备上的操作。这些数据的示例包括用于在计算机设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

处理器82b，与存储器81b耦合，用于执行存储器81b中的计算机程序，以用于：基于所述分享页面，获取所述第一用户要分享的资源信息；

基于所述资源信息生成资源分享所需的第一链接，所述第一链接指向的页面包含触发控件，所述触发控件与指定行为对应；

通过通信组件84b将所述第一链接发送给第二用户，以使所述第二用户通过所述触发控件对所述第一用户发生指定行为并获取所述第一用户分享的资源。

在一可选实施例中，处理器82b在获取所述第一用户要分享的资源信息时，具体用于：响应第一用户在所述分享页面上的输入操作，获取所述第一用户输入的资源总量和资源个数作为所述资源信息。

进一步，处理器82b在生成资源分享所需的第一链接时，具体用于：根据所述资源总量，从所述第一用户的资源账户中转出相应资源到中间账户；根据所述资源个数，将所述资源总量拆分为N个可获取的资源分量，N表示所述资源个数，是正整数；根据所述触发控件和所述N个可获取的资源分量，生成所述第一链接。

在一可选实施例中，处理器82b在获取所述第一用户要分享的资源信息时，还用于：获取所述第一用户输入的指引文本信息作为所述资源信息，所述指引文本信息体现资源分享与发生指定行为之间的关联关系。基于此，处理器82b在生成所述第一链接时，具体用于：根据所述触发控件、所述N个可获取的资源分量以及所述指引文本信息，生成所述第一链接，所述第一链接指向的页面还包括所述指引文本信息。

在一可选实施例中，处理器82b还用于在基于所述分享页面，获取所述第一用户要分享的资源信息的过程中，执行以下判断操作：

判断所述第一用户输入的资源总量是否满足设定的资源总量要求；

判断所述第一用户输入的资源个数是否满足设定的资源个数要求；

判断所述第一用户输入的指引文本信息是否符合设定的用语规范；

若上述判断操作的判断结果均为是，则获取所述第一用户输入的资源总量、资源个数和指引文本信息作为所述资源信息。

在一可选实施例中，处理器82b还用于：在获取所述第一用户要分享的资源信息之前，执行以下至少一种判断操作：

判断所述第一用户在本轮分享活动中分享资源的总次数是否已经达到本轮分享活动允许的次数上限，每轮分享活动包括至少一个活动时段；

判断所述第一用户在当前活动时段内分享资源的次数是否已经达到当前活动时段允许的次数上限；

若所述至少一种判断操作的判断结果均为否，则允许所述第一用户在所述分享页面上执行输入操作。

在一可选实施例中，处理器82b还用于：在将所述第一链接发送给第二用户之后，根据所述第一用户再次发起的分享请求，通过显示器83b显示所述分享页面，所述分享页面显示有所述第一用户已经分享的资源的信息以及分享控件；响应于所述第一用户对所述分享控件的触发操作，通信组件84b继续将所述第一链接发送给第三用户，所述第三用户是任何未获取过所述第一用户分享的资源的用户。

在一可选实施例中，处理器82b还用于：通信组件84b接收所述第二用户的资源获取请求；判断所述N个可获取的资源分量是否还有剩余；若是，从剩余的资源分量中，确定所述第二用户获取到的目标资源分量，并向所述第二用户返回所述目标资源分量；以及记录资源获取流水信息，所述资源获取流水信息包含所述第二用户获取到所述目标资源分量的信息。

在一可选实施例中，处理器82b还用于：通信组件84b接收所述第二用户的资源转移请求，所述资源转移请求包括资源转移行为涉及的第三方资源账户；根据所述资源获取流水信息，将所述目标资源分量对应的资源从所述中间账户转移到所述第三方资源账户。

可选地，处理器82b还用于：在接收所述第二用户的资源转移请求之前，判断所述目标资源分量对应的资源的有效期是否结束；若结束，将所述目标资源分量对应的资源从所述中间账户退回至所述第一用户的资源账户。

进一步，处理器82b还用于：在将所述目标资源分量对应的资源从所述中间账户转移到所述第三方资源账户之后，记录资源转移流水信息，所述资源转移流水信息包括所述目标资源分量对应的资源从所述中间账户转移到所述第三方资源账户的相关信息。

进一步，如图8b所示，该计算机设备还包括：电源组件85b、音频组件86b等其它组件。图8b中仅示意性给出部分组件，并不意味着计算机设备只包括图8b所示组件。本实施例的计算机设备可以实现为台式电脑、笔记本电脑、智能手机或IOT设备等终端设备，也可以是常规服务器、云服务器或服务器阵列等服务端设备。相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述图7a所示方法实施例中的各步骤。

除上述计算机设备之外，本申请实施例还提供一种服务端设备，该服务端设备包括：存储器、处理器和通信组件；存储器用于存储计算机程序；处理器与存储器耦合，用于执行存储器中的计算机程序，以用于：

通过通信组件接收第一终端设备发送的资源分享请求，该请求携带有第一用户要分享的资源信息，该资源信息包括：资源总量和资源个数；

根据资源总量，从第一用户的资源账户中转出相应资源到中间账户；

根据资源个数，将资源总量拆分为N个可获取的资源分量，N表示资源个数，是正整数；

根据触发控件和N个可获取的资源分量，生成第一链接。

可选地，上述处理器还用于：通过通信组件接收第二用户的资源获取请求；判断上述N个可获取的资源分量是否还有剩余；若是，从剩余的资源分量中，确定第二用户获取到的目标资源分量，并向第二用户返回目标资源分量；以及记录资源获取流水信息，资源获取流水信息包含第二用户获取到目标资源分量的信息。

进一步，上述处理器还用于：通过通信组件接收第二用户的资源转移请求，资源转移请求包括资源转移行为涉及的第三方资源账户；根据资源获取流水信息，将目标资源分量对应的资源从中间账户转移到第三方资源账户。

进一步，上述处理器还用于：在接收第二用户的资源转移请求之前，判断目标资源分量对应的资源的有效期是否结束；若结束，将目标资源分量对应的资源从中间账户退回至第一用户的资源账户。

进一步，上述处理器还用于：在将目标资源分量对应的资源从中间账户转移到第三方资源账户之后，记录资源转移流水信息，资源转移流水信息包括目标资源分量对应的资源从中间账户转移到第三方资源账户的相关信息。

上述图8a和图8b中的存储器可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

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

上述图8a和图8b中中的显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

上述图8a和图8b中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理***，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

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

本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (32)

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

显示第一链接指向的页面，所述第一链接是第一用户分享的；

响应第二用户对所述页面上触发控件的操作，确定所述第二用户对所述第一用户发生指定行为；以及

为所述第二用户获取所述第一用户分享的资源；其中，所述触发控件与所述指定行为对应。

2.根据权利要求1所述的方法，其特征在于，在响应第二用户对所述页面上第一控件的触发操作之前，还包括：

判断所述第二用户是否满足对所述第一用户发生指定行为的条件；

若满足，在所述页面上显示所述触发控件。

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

若不满足，在所述页面上显示第一提示信息，以提示所述第二用户其不满足对所述第一用户发生指定行为的条件。

4.根据权利要求3所述的方法，其特征在于，在所述页面上显示所述触发控件或所述第一提示信息，包括：

在所述页面上显示第一悬浮窗，所述第一悬浮窗中包含所述触发控件或第一提示信息。

5.根据权利要求2所述的方法，其特征在于，判断所述第二用户是否满足对所述第一用户发生指定行为的条件包括：执行以下至少一种判断操作：

判断所述第二用户在当前活动时段内对所述第一用户发生指定行为的次数是否已经达到上限；

判断所述第一用户参与的本轮分享活动是否已经结束，每轮分享活动包括至少一个活动时段；

判断所述第二用户在当前活动时段内是否已经对所述第一用户发生过指定行为；

若任一判断操作的判断结果为是，确定所述第二用户不满足对所述第一用户发生指定行为的条件；

若所述至少一种判断操作的判断结果均为否，确定所述第二用户满足对所述第一用户发生指定行为的条件。

6.根据权利要求1所述的方法，其特征在于，响应第二用户对所述页面上触发控件的操作，确定所述第二用户对所述第一用户发生指定行为，包括：

响应第二用户对所述触发控件的触发操作，向服务端发送信息处理请求，以请求所述服务端为所述第一用户进行与所述指定行为相关的处理操作；以及

若接收到所述服务端返回的处理成功消息，确定所述第二用户对所述第一用户发生指定行为。

7.根据权利要求1所述的方法，其特征在于，在为所述第二用户获取所述第一用户分享的资源之前，还包括：

判断所述第一用户分享的资源是否仍处于可获取状态；

若所述第一用户分享的资源仍处于可获取状态，为所述第二用户获取所述第一用户分享的资源。

8.根据权利要求7所述的方法，其特征在于，判断所述第一用户分享的资源是否仍处于可获取状态包括：执行以下至少一种判断操作：

判断所述第一用户分享的资源是否已过期；

判断所述第一用户分享的资源是否已经没有剩余；

若任一判断操作的判断结果为是，确定所述第一用户分享的资源处于不可获取状态；

若所述至少一种判断操作的判断结果均为否，确定所述第一用户分享的资源仍处于可获取状态。

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

若所述第一用户分享的资源处于不可获取状态，在所述页面上显示第二提示信息，以提示所述第二用户是否继续对所述第一用户发生指定行为；以及

在所述第一用户分享的资源处于不可获取状态的情况下，响应所述第二用户对所述触发控件的操作，确定所述第二用户对所述第一用户发生指定行为。

10.根据权利要求1-9任一项所述的方法，其特征在于，为所述第二用户获取所述第一用户分享的资源，包括：

向服务端发送资源获取请求，以供所述服务端确定所述第二用户能否从所述第一用户分享的资源中获取到资源并在能够获取到的情况下返回所述第二用户获取到的目标资源分量；

接收所述服务端返回的所述第二用户获取到的目标资源分量，并在所述页面上显示所述目标资源分量。

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

在所述页面上，显示查看控件；以及

响应所述第二用户对所述查看控件的触发操作，显示所述第一用户的资源分享详情。

12.根据权利要求11所述的方法，其特征在于，在所述页面上，显示所述目标资源分量以及所述查看控件，包括：

在所述页面上显示第二悬浮窗，所述第二悬浮窗中包含所述目标资源分量以及所述查看控件。

13.根据权利要求10所述的方法，其特征在于，所述第一用户分享的资源被存储在中间账户中；在显示所述目标资源分量之后，还包括：

若检测到所述第二用户在第一应用中发起资源转移行为，确定资源转移行为涉及的第三方资源账户，所述第一应用是所述页面所属的应用；

向所述服务端发送资源转移请求，以请求所述服务端将所述目标资源分量对应的资源从所述中间账户转移到所述第三方资源账户中。

14.根据权利要求1-9任一项所述的方法，其特征在于，所述指定行为包括以下至少一种：助力行为、浏览行为、代付行为和评论行为。

15.根据权利要求14所述的方法，其特征在于，所述页面为PK活动中的PK页面，或者，为砍价活动的砍价页面，或者，团购活动中的商品详情页面，或者，资源领取活动中的资源领取页面。

16.根据权利要求1-9任一项所述的方法，其特征在于，所述第一链接为淘口令，二维码或URL链接。

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

根据第一用户的分享请求，显示分享页面；

基于所述分享页面，获取所述第一用户要分享的资源信息；

基于所述资源信息生成资源分享所需的第一链接，所述第一链接指向的页面包含触发控件，所述触发控件与指定行为对应；

将所述第一链接发送给第二用户，以使所述第二用户通过所述触发控件对所述第一用户发生指定行为并获取所述第一用户分享的资源。

18.根据权利要求17所述的方法，其特征在于，基于所述分享页面，获取所述第一用户要分享的资源信息，包括：

响应第一用户在所述分享页面上的输入操作，获取所述第一用户输入的资源总量和资源个数作为所述资源信息。

19.根据权利要求18所述的方法，其特征在于，基于所述资源信息生成资源分享所需的第一链接，包括：

根据所述资源总量，从所述第一用户的资源账户中转出相应资源到中间账户；

根据所述资源个数，将所述资源总量拆分为N个可获取的资源分量，N表示所述资源个数，是正整数；

根据所述触发控件和所述N个可获取的资源分量，生成所述第一链接。

20.根据权利要求19所述的方法，其特征在于，基于所述分享页面，获取所述第一用户要分享的资源信息还包括：获取所述第一用户输入的指引文本信息作为所述资源信息，所述指引文本信息体现资源分享与发生指定行为之间的关联关系；

所述根据所述触发控件和所述N个可获取的资源分量，生成所述第一链接，包括：根据所述触发控件、所述N个可获取的资源分量以及所述指引文本信息，生成所述第一链接，所述第一链接指向的页面还包括所述指引文本信息。

21.根据权利要求20所述的方法，其特征在于，在基于所述分享页面，获取所述第一用户要分享的资源信息的过程中，还包括以下判断操作：

判断所述第一用户输入的资源总量是否满足设定的资源总量要求；

判断所述第一用户输入的资源个数是否满足设定的资源个数要求；

判断所述第一用户输入的指引文本信息是否符合设定的用语规范；

若上述判断操作的判断结果均为是，则获取所述第一用户输入的资源总量、资源个数和指引文本信息作为所述资源信息。

22.根据权利要求21所述的方法，其特征在于，在基于所述分享页面，获取所述第一用户要分享的资源信息之前，还包括：

判断所述第一用户在本轮分享活动中分享资源的总次数是否已经达到本轮分享活动允许的次数上限，每轮分享活动包括至少一个活动时段；

判断所述第一用户在当前活动时段内分享资源的次数是否已经达到当前活动时段允许的次数上限；

若所述至少一种判断操作的判断结果均为否，则允许所述第一用户在所述分享页面上执行输入操作。

23.根据权利要求17-22任一项所述的方法，其特征在于，在将所述第一链接发送给第二用户之后，还包括：

根据所述第一用户再次发起的分享请求，显示所述分享页面，所述分享页面显示有所述第一用户已经分享的资源的信息以及分享控件；

响应于所述第一用户对所述分享控件的触发操作，继续将所述第一链接发送给第三用户，所述第三用户是任何未获取过所述第一用户分享的资源的用户。

24.根据权利要求19-22任一项所述的方法，其特征在于，还包括：

接收所述第二用户的资源获取请求；

判断所述N个可获取的资源分量是否还有剩余；

若是，从剩余的资源分量中，确定所述第二用户获取到的目标资源分量，并向所述第二用户返回所述目标资源分量；以及

记录资源获取流水信息，所述资源获取流水信息包含所述第二用户获取到所述目标资源分量的信息。

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

接收所述第二用户的资源转移请求，所述资源转移请求包括资源转移行为涉及的第三方资源账户；

根据所述资源获取流水信息，将所述目标资源分量对应的资源从所述中间账户转移到所述第三方资源账户。

26.根据权利要求25所述的方法，其特征在于，在接收所述第二用户的资源转移请求之前，还包括：

判断所述目标资源分量对应的资源的有效期是否结束；

若结束，将所述目标资源分量对应的资源从所述中间账户退回至所述第一用户的资源账户。

27.根据权利要求25所述的方法，其特征在于，在将所述目标资源分量对应的资源从所述中间账户转移到所述第三方资源账户之后，还包括：

记录资源转移流水信息，所述资源转移流水信息包括所述目标资源分量对应的资源从所述中间账户转移到所述第三方资源账户的相关信息。

28.一种助力方法，其特征在于，包括：

显示第一用户分享的第一链接；

响应第二用户对所述第一链接的点击操作，显示所述第一链接指向的红包领取页面；

响应所述第二用户对所述红包领取页面上助力控件的操作，对所述第一用户进行助力，并为所述第二用户获取所述第一用户分享的红包。

29.一种助力方法，其特征在于，包括：

根据第一用户的助力请求，显示红包分享页面；

基于所述红包分享页面，获取所述第一用户要分享的红包信息；

基于所述红包信息生成分享红包所需的第一链接，所述第一链接指向的红包领取页面包含助力控件；

将所述第一链接发送给第二用户，以供所述第二用户通过所述助力控件为所述第一用户助力并获取所述第一用户分享的红包。

30.一种计算机设备，其特征在于，包括：存储器、处理器和显示器；

所述显示器，用于显示第一链接指向的页面，所述第一链接是第一用户分享的；

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：

响应第二用户对所述页面上触发控件的操作，确定所述第二用户对所述第一用户发生指定行为；以及

为所述第二用户获取所述第一用户分享的资源；其中，所述触发控件与所述指定行为对应。

31.一种计算机设备，其特征在于，包括：存储器、处理器和显示器；

所述显示器，用于根据第一用户的分享请求，显示分享页面；

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：

基于所述分享页面，获取所述第一用户要分享的资源信息；

基于所述资源信息生成资源分享所需的第一链接，所述第一链接指向的页面包含触发控件，所述触发控件与指定行为对应；

将所述第一链接发送给第二用户，以使所述第二用户通过所述触发控件对所述第一用户发生指定行为并获取所述第一用户分享的资源。

32.一种存储有计算机程序的计算机可读存储介质，其特征在于，当所述计算机程序被处理器执行时，致使所述处理器实现权利要求1-29中任一项所述方法的步骤。

Images