CN115905665A - 一种基于私域流量的发卡引流方法、系统、设备及介质 - Google Patents

Abstract

本发明提出了一种基于私域流量的发卡引流方法、系统、设备及介质，涉及互联网技术领域。其通过将发卡的流程处理基于客户端包括的目标用户的资源账号在网页服务器中进行处理，使得即使在发卡过程中网页出现异常的时候，应用程序客户端的各个功能依然能够继续使用。从而可以避免应用程序客户端在发卡过程中出现崩溃时，导致应用程序客户端中的其他功能不能继续使用，从而影响应用程序客户端的正常运行的现象发生。并且，通过本发明的方法，在低成本的情况下，以趣味互动的形式将企业私域流量充分利用起来，从而可以将私域流量有效的转换为实际的目标客户，用以解决获客难的问题。

Description

一种基于私域流量的发卡引流方法、系统、设备及介质

技术领域

本发明涉及互联网技术领域，具体而言，涉及一种基于私域流量的发卡引流方法、系统、设备及介质。

背景技术

在目前大环境下，不论是传统电商还是线下门店都面临着获客难，获客成本高的问题。从而，相应的可以考虑充分利用企业私域流量进行目标客户的获取工作。其中，企业私域流量，是指企业业务范围内触达客户，所构造的消费渠道或经营手段，这是企业可以直接触达、反复利用的流量，而企业能够直接接触客户，并向客户销售产品，而不需要像早期一样，靠平台推荐和广告曝光。其载体可以是线下消费场景，也可以是线上的某个虚拟服务。

但是，对于企业私域流量而言，其在现有技术中仍然是一种客户思维，在如何将其落实到具体实际上来说，却缺乏相应的方法，特别是在电商环境下具有较多的企业私域流量情况下，如何在低成本且转换率较高的基础上将企业私域流量转换为目标客户一直是一个迫切需要解决的问题。

发明内容

本发明的目的在于提供一种基于私域流量的发卡引流方法、系统、设备及介质，其利用趣味互动的形式进行低成本的将现有的私域流量充分利用起来，从而将私域流量有效的转换为实际的目标客户，用以解决获客难的问题。

本发明的实施例是这样实现的：

第一方面，本申请实施例提供一种基于私域流量的发卡引流方法，包括以下步骤：

步骤S101：网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，上述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡；步骤S102：网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，上述第二发卡请求信息用于指示上述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡；步骤S103：后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

在本发明的一些实施例中，上述发卡请求的类别为获取登录卡，则上述发卡流程包括：

获取目标用户的资源账号对应的手机号，进行redis幂判断；redis幂判断通过后基于发卡请求的类别和目标用户的资源账号对应的手机号查询是否已获取登录卡，若否，则基于查询cif信息生成对应的卡号，并发放对应的登录卡。

在本发明的一些实施例中，上述发卡请求的类别为获取消费卡，则上述发卡流程包括：

响应于目标用户使用应用程序客户端进行相应的积分消费后的获取消费卡请求，进入消费卡发卡流程；对消费卡发卡流程对应的活动规则信息进行校验，若校验通过，则进入下一步；获取目标用户的资源账号对应的手机号，进行redis幂判断；redis幂判断通过后基于发卡请求的类别和目标用户的资源账号对应的手机号查询是否已获取消费卡，若否，则基于查询cif信息生成对应的卡号，发放对应的消费卡，并根据发卡记录表判断是否已集齐，若是，则生成相应的集齐卡表，并新增发卡记录。

在本发明的一些实施例中，上述发卡请求的类别为获取助力卡，则上述发卡流程包括：

响应于目标用户邀请好友用户为自己助力的请求，进入助力发卡流程；基于目标用户的资源账号对应的客户信息判断是否自己为自己助力，若是，则生成相应的提示信息进行提示不能为自己助力，若否，则判断是否首次助力，若是，则按照预设助力规则进行助力卡发送，若否，则判断是否满足助力条件，并根据判断结果建立助力规则进行助力卡发送。

在本发明的一些实施例中，上述判断是否满足助力条件包括：

获取目标用户和好友用户的资源账号对应的手机号信息生成相应的Key，并根据Key判断是否已相互助力，若否，则进入下一步；基于redis计数器计算助力人助力次数与预置阈值的对比关系进行判断是否满足助力次数要求。

第二方面，本申请实施例提供一种基于私域流量的发卡引流系统，其包括：

请求接收模块，用于网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，上述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡；请求发送模块，用于网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，上述第二发卡请求信息用于指示上述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡；信息展示模块，用于后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

第三方面，本申请实施例提供一种电子设备，其包括存储器，用于存储一个或多个程序；处理器。当上述一个或多个程序被上述处理器执行时，实现如上述第一方面中任一项上述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述第一方面中任一项上述的方法。

相对于现有技术，本发明的实施例至少具有如下优点或有益效果：

本发明的实施例提出了一种基于私域流量的发卡引流方法，其通过将发卡的流程处理基于客户端包括的目标用户的资源账号在网页服务器中进行处理，使得即使在发卡过程中网页出现异常的时候，应用程序客户端的各个功能依然能够继续使用。从而可以避免应用程序客户端在发卡过程中出现崩溃时，导致应用程序客户端中的其他功能不能继续使用，从而影响应用程序客户端的正常运行的现象发生。并且，通过本发明的方法，可以在低成本的情况下，以趣味互动的形式将企业私域流量充分利用起来，从而将私域流量有效的转换为实际的目标客户，用以解决获客难的问题。

附图说明

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

图1为本发明一种基于私域流量的发卡引流方法一实施例的流程图；

图2为本发明实施例中XX步骤的具体流程图；

图3为本发明实施例；

图4为本发明一种基于私域流量的发卡引流系统一实施例的结构框图；

图5为本发明实施例提供的一种电子设备的结构框图。

图标：1、请求接收模块；2、请求发送模块；3、信息展示模块；4、处理器；5、存储器；6、数据总线。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的各个实施例及实施例中的各个特征可以相互组合。

实施例1

针对企业私域流量而言，大家都知道很重要，但是却缺乏相应的方法去处理经营企业自己拥有的私域流量。经常就是被动的等着客户上门，当然，也有尝试做微信个人号的，但只是把微信当作销售的一个渠道。比如传统企业中某个小区附近的生活超市，添加微信就提醒客户可以微信要货，送货上门，甚至客户添加微信后，便再也不联系，除非因为需求主动联系。小区周边服务，因为某些场景下跑腿业务的必须性，还能有一定的效果。但是，在其他的企业中，比如电商环境下，这样只会让大多数客户白白流失。

因此，请参阅图1-3，本申请实施例提供了一种基于私域流量的发卡引流方法，其利用趣味互动的形式进行低成本的将现有的私域流量充分利用起来，从而将私域流量有效的转换为实际的目标客户，用以解决获客难的问题。该一种基于私域流量的发卡引流方法包括以下步骤：

步骤S101：网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，上述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡。

上述步骤中，目标用户的资源账号的第一发卡请求信息是在网页服务器进行接收的，从而可以保证后续在客户端进行相应的发卡流程过程中出现崩溃的时候，客户端中的其他功能也能继续使用，从而可以保证客户端的稳定运行。即将后续的发卡流程与客户端中的其他功能进行分离，使得客户端中的其他功能不受发卡流程的影响。并且，通过将发卡请求信息的类别设为简单的获取登录卡、获取消费卡和获取助力卡类别，不仅可以便于目标客户理解，并且后续可以针对具体的类别进行相应的发卡处理，从而可以促进用户以趣味互动进行参与活动，达到将私域流量进行简单高效率的转换为目标用户的目的。

步骤S102：网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，上述第二发卡请求信息用于指示上述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡。

上述步骤中，在确定了基础的三种发卡请求信息后，即可开始根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，用以为目标客户提供简单有趣的趣味互动，提升用户活跃度，在趣味互动过程中实现私域流量的高效转换。

具体地，请参阅图2，若上述发卡请求的类别为获取登录卡，则上述发卡流程包括：

步骤S201：获取目标用户的资源账号对应的手机号，进行redis幂判断。

上述步骤中，进行redis幂判断是指利用redis实现接口幂等性，通俗的说就是一个接口,多次发起同一个请求,必须保证操作只能执行一次。例如：订单接口,不能多次创建订单；支付接口，重复支付同一笔订单只能扣一次钱；支付宝回调接口，可能会多次回调，必须处理重复回调；普通表单提交接口，因为网络超时等原因多次点击提交，只能成功一次等等。也就是说，通过进行redis幂判断，可以保证接下来的发卡流程唯一，不会因此出现重复发卡的问题，保证数据的准确性。示例性地，如何进行redis幂判断可以包括：

(1)数据库建立唯一性索引，可以保证最终插入数据库的只有一条数据；

(2)token机制，每次接口请求前先获取一个token，然后在下次请求的时候在请求的header体中加上这个token，后台进行验证，如果验证通过删除token，下次请求再次判断token；

(3)悲观锁或者乐观锁，悲观锁可以保证每次for update的时候其他sql无法update数据(在数据库引擎是innodb的时候,select的条件必须是唯一索引,防止锁全表)；

(4)先查询后判断，首先通过查询数据库是否存在数据，如果存在证明已经请求过了，直接拒绝该请求，如果没有存在，就证明是第一次进来，直接放行。

步骤S202：redis幂判断通过后基于发卡请求的类别和目标用户的资源账号对应的手机号查询是否已获取登录卡，若否，则基于查询cif信息生成对应的卡号，并发放对应的登录卡。

上述步骤中，在保证了此次发卡流程对应的请求唯一的情况下，即可开始判断其是否已经获取了登录卡，并在未获取的时候基于查询cif信息生成对应的卡号，发放对应的登录卡。从而不仅可以保证目标用户获取的登录卡唯一，而且可以避免重复对同一用户进行发放登录卡的问题出现。

另外，请参阅图3，若上述发卡请求的类别为获取消费卡，则上述发卡流程包括：

步骤S301：响应于目标用户使用应用程序客户端进行相应的积分消费后的获取消费卡请求，进入消费卡发卡流程。

上述步骤中，目标用户在应用程序客户端进行相应的积分消费后，则可以基于其积分消费情况进行响应目标用户的获取消费卡请求，从而为后续发卡流程提供原始数据支撑。

步骤S302：对消费卡发卡流程对应的活动规则信息进行校验，若校验通过，则进入下一步。

上述步骤中，通过对活动规则信息进行类似活动时间条件、活动地区条件等具有限定性的条件进行校验，从而保证后续能够为满足条件的目标用户提供相应的发卡流程。

步骤S303：获取目标用户的资源账号对应的手机号，进行redis幂判断，其具体原理请参阅步骤S201部分的说明，此处不再赘述。

步骤S304：redis幂判断通过后基于发卡请求的类别和目标用户的资源账号对应的手机号查询是否已获取消费卡，若否，则基于查询cif信息生成对应的卡号，发放对应的消费卡，并根据发卡记录表判断是否已集齐，若是，则生成相应的集齐卡表，并新增发卡记录。

上述步骤中，在发放了对应的消费卡后，则此时可能已经存在登录卡、消费卡和助力卡均已集齐的情况，因此，此时可以通过发卡记录表判断是否已集齐，并在已经集齐的情况下生成相应的集齐卡表，使得目标用户可以根据这个集齐情况生成的发卡记录进行后续的集卡成功使用。例如，可以在集卡成功后兑换相应的金融券、消费券、不可提现金或者实物商品等等(具体的需要根据实际情况进行预先设定兑换列表，提升目标用户的集卡主动性，从而提高将企业私域流量进行转换的效率)。

再者，若上述发卡请求的类别为获取助力卡，则上述发卡流程包括：

步骤S401：响应于目标用户邀请好友用户为自己助力的请求，进入助力发卡流程；

步骤S402：基于目标用户的资源账号对应的客户信息判断是否自己为自己助力，若是，则生成相应的提示信息进行提示不能为自己助力，若否，则判断是否首次助力，若是，则按照预设助力规则进行助力卡发送，若否，则判断是否满足助力条件，并根据判断结果建立助力规则进行助力卡发送。

上述步骤中，首先通过目标用户和好友用户之间的助力，用以进一步的提高互动的趣味性，以及其活跃度，可以进一步的提高将企业私域流量进行转换的效率。其次，在助力的时候，通过判断是否自己为自己助力，可以避免无效的助力情况发生(即可以保证私域流量的转换准确高效)。并且通过对满足助力条件的请求进行建立对应的助力规则进行助力卡发送，从而有效的保证助力卡的发放更加灵活多变且具有趣味性，提高目标用户和好友用户之间的交互性。

其中，通过软件进行具体实现的时候可以包括：在应用程序客户端kafka消费后，根据DTO参数转换为BO，先查助力人助力数量表，判断是否为空以及第几次助力。若助力人助力数量为空，则为首次助力，查询CIF获取助力人客户信息，发助力人代金券(落发券记录表，调代金券发券，更新发券记录表)，且进行首次发券类型定时任务补偿，查询被助力人助力数量表，若存在，则更新被助力人助力数量表，落助力人助力数量表，助力明细表，若不存在，则落被助力人、助力人助力数量表，助力明细表，发卡记录表，用户集齐卡则落集齐卡表。发送大数据kafka消息。

示例性地，上述判断是否满足助力条件包括：

获取目标用户和好友用户的资源账号对应的手机号信息生成相应的Key，并根据Key判断是否已相互助力，若否，则进入下一步；基于redis计数器计算助力人助力次数与预置阈值的对比关系进行判断是否满足助力次数要求。

上述步骤中，通过目标用户和好友用户对应的手机号信息生成唯一的Key，从而可以根据这个唯一的Key判断是否已相互助力。以至于，接下来可以通过获取助力人助力次数是否已经不满足助力条件，从而筛选出不符合助力的情况，避免助力资源的重复利用，进一步提高目标用户之间的活跃度。其中，助力人为目标用户邀请的好友用户，助力次数与预置阈值的对比关系可以是简单的判断其总助力次数是否已经超过一个预先设定的值(例如10次)，当然也可以根据实际情况需要选择更加复杂的对比关系。

步骤S103：后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

上述步骤中，在客户通过相应的发卡流程进行相应的卡券获取之后(获取登录卡、获取消费卡或获取助力卡)，则可以开始将对应的发卡结果信息展示给目标用户，使其及时清楚的了解到卡券获取情况，提高其参与感。并且根据此次发卡结果信息及目标用户的资源账号的历史发卡情况将结果展示给目标用户，将可以使得目标用户了解到其距离集齐三张卡券有多少差距，提高其交互参与度，能够达到更有效的引流作用，即可以提升将私域流量转换为目标客户的效率。

实施例2

请参阅图4，本申请实施例提供了一种基于私域流量的发卡引流系统，其包括：

请求接收模块1，用于网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，上述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡；请求发送模块2，用于网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，上述第二发卡请求信息用于指示上述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡；信息展示模块3，用于后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

上述系统具体实现过程请参照实施例1中提供的一种基于私域流量的发卡引流方法，在此不再赘述。

实施例3

请参阅图5，本申请实施例提供了一种电子设备，该电子设备包括至少一个处理器4、至少一个存储器5和数据总线6；其中：处理器4与存储器5通过数据总线6完成相互间的通信；存储器5存储有可被处理器4执行的程序指令，处理器4调用程序指令以执行一种基于私域流量的发卡引流方法。例如实现：

步骤S101：网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，上述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡；步骤S102：网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，上述第二发卡请求信息用于指示上述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡；步骤S103：后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

其中，存储器5可以是但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read Only Memory，ROM)，可编程只读存储器(Programmable Read-OnlyMemory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

处理器4可以是一种集成电路芯片，具有信号处理能力。该处理器4可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(NetworkProcessor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

可以理解，图5所示的结构仅为示意，电子设备还可包括比图5中所示更多或者更少的组件，或者具有与图5所示不同的配置。图5中所示的各组件可以采用硬件、软件或其组合实现。

实施例4

本发明提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器4执行时实现一种基于私域流量的发卡引流方法。例如实现：

步骤S101：网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，上述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡；步骤S102：网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，上述第二发卡请求信息用于指示上述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡；步骤S103：后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

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

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

Claims (8)

1.一种基于私域流量的发卡引流方法，其特征在于，包括以下步骤：

步骤S101：网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，所述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡；

步骤S102：网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，所述第二发卡请求信息用于指示所述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡；

步骤S103：后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

2.如权利要求1所述的一种基于私域流量的发卡引流方法，其特征在于，所述发卡请求的类别为获取登录卡，则所述发卡流程包括：

获取目标用户的资源账号对应的手机号，进行redis幂判断；

redis幂判断通过后基于发卡请求的类别和目标用户的资源账号对应的手机号查询是否已获取登录卡，若否，则基于查询cif信息生成对应的卡号，并发放对应的登录卡。

3.如权利要求1所述的一种基于私域流量的发卡引流方法，其特征在于，所述发卡请求的类别为获取消费卡，则所述发卡流程包括：

响应于目标用户使用应用程序客户端进行相应的积分消费后的获取消费卡请求，进入消费卡发卡流程；

对消费卡发卡流程对应的活动规则信息进行校验，若校验通过，则进入下一步；

获取目标用户的资源账号对应的手机号，进行redis幂判断；

redis幂判断通过后基于发卡请求的类别和目标用户的资源账号对应的手机号查询是否已获取消费卡，若否，则基于查询cif信息生成对应的卡号，发放对应的消费卡，并根据发卡记录表判断是否已集齐，若是，则生成相应的集齐卡表，并新增发卡记录。

4.如权利要求1所述的一种基于私域流量的发卡引流方法，其特征在于，所述发卡请求的类别为获取助力卡，则所述发卡流程包括：

响应于目标用户邀请好友用户为自己助力的请求，进入助力发卡流程；

基于目标用户的资源账号对应的客户信息判断是否自己为自己助力，若是，则生成相应的提示信息进行提示不能为自己助力，若否，则判断是否首次助力，若是，则按照预设助力规则进行助力卡发送，若否，则判断是否满足助力条件，并根据判断结果建立助力规则进行助力卡发送。

5.如权利要求4所述的一种基于私域流量的发卡引流方法，其特征在于，所述判断是否满足助力条件包括：

获取目标用户和好友用户的资源账号对应的手机号信息生成相应的Key，并根据Key判断是否已相互助力，若否，则进入下一步；

基于redis计数器计算助力人助力次数与预置阈值的对比关系进行判断是否满足助力次数要求。

6.一种基于私域流量的发卡引流系统，其特征在于，包括：

请求接收模块，用于网页服务器接收浏览器发送的基于目标用户的资源账号的第一发卡请求信息，所述发卡请求信息的类别包括获取登录卡、获取消费卡和获取助力卡；

请求发送模块，用于网页服务器基于发卡请求的类别发送对应的第二发卡请求信息至应用程序客户端所对应的后台服务器，所述第二发卡请求信息用于指示所述后台服务器进行响应相应的发卡流程，并根据目标用户的资源账号的历史发卡情况及目标用户的操作情况建立预设发卡机制进行发卡或发卡，其中发卡流程的类别包括发放登录卡、发放消费卡和发放助力卡；

信息展示模块，用于后台服务器基于发卡流程的处理结果通过可视化语言数据向目标用户展示发卡结果信息，并根据发卡结果信息及目标用户的资源账号的历史发卡情况建立提醒预设机制利用可视化的自然语言数据节点向提醒目标用户集卡情况信息。

7.一种电子设备，其特征在于，包括至少一个处理器、至少一个存储器和数据总线；其中：所述处理器与所述存储器通过所述数据总线完成相互间的通信；所述存储器存储有被所述处理器执行的程序指令，所述处理器调用所述程序指令以执行如权利要求1-5任一项所述的方法。

8.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1-5中任一项所述的方法。

Images