CN112308563B - 获客数据处理方法与节点 - Google Patents

Abstract

本发明实施例提供一种获客数据处理方法，基于用于存储获客数据的公有链，公有链包括智能合约；智能合约至少包括：获客协议和获客结算操作逻辑；获客协议包括：签署方注册信息及结算条件；签署方包括：渠道提供方和业务提供方；注册信息至少包括使用者标识；其中，渠道提供方的服务器用于向业务使用方提供访问渠道，业务使用方通过访问渠道访问业务提供方的服务器；业务提供方的服务器用于：在业务使用方通过预设校验后，向公有链发起获客结算交易；该方法包括：接收获客结算交易请求(指定了：渠道提供方的使用者标识、业务提供方的使用者标识和第一业务使用方的区块链地址)；触发智能合约执行获客结算操作逻辑，得到结算数据并记录至公有链。

Description

获客数据处理方法与节点

技术领域

本发明涉及大数据处理技术领域，特别涉及获客数据处理方法与节点。

背景技术

随着移动互联网普及度越来越高，很多商家(企业)会选择第三方渠道商来帮助自身扩大客户群体。

请参见图1，当前的渠道获客主要通过以下方式进行：

商家(业务提供方)事先给渠道商(渠道提供方)分配唯一标志信息；

渠道商将标志信息加入到商家URL中；

在客户(业务使用方)访问该URL后，若为新客，商家发送给客户新客奖励；

商家识别标志信息，确定该标志信息对应的渠道商，若干时间后进行结算。

上述获客结算流程存在如下不足：商家与渠道商的数据角度不同，获客数据难以一致。这是因为，在商家视角，是将真正通过访问渠道访问商家服务器的客户，看作有效客户。

而渠道商为客户提供的是访问渠道(例如URL链接)，这个访问渠道指向的是商家的服务器。客户是否通过访问渠道访问了商家服务器，渠道商的服务器自身是无法获知的。因此，二者的数据可能出现不一致的情况。同时，二者的数据维护在不同的系统，商家的数据对于渠道商是不透明的，也存在一定的不可靠性，进而可能引起商家与渠道商间的合作纠纷。

发明内容

有鉴于此，本发明实施例提供获客数据处理方法与节点，以解决现有获客流程中数据不透明、不可靠的问题。

为实现上述目的，本发明实施例提供如下技术方案：

一种获客数据处理方法，基于用于存储获客数据的公有链，所述公有链包括智能合约；所述智能合约至少包括：签署生效的获客协议和相应的获客结算操作逻辑；所述获客协议包括：签署方的注册信息以及结算条件；所述签署方包括：渠道提供方和业务提供方；所述注册信息至少包括使用者标识；其中，所述渠道提供方的服务器用于向业务使用方提供访问渠道，业务使用方通过所述访问渠道访问所述业务提供方的服务器；所述业务提供方的服务器用于：在业务使用方通过预设校验后，向所述公有链发起获客结算交易；

所述方法包括：

接收获客结算交易请求；其中，所述获客结算交易请求至少指定了：第一标识、第二标识和第三标识；所述第一标识为渠道提供方的使用者标识；所述第二标识为业务提供方的使用者标识；所述第三标识为第一业务使用方的区块链地址；

触发所述智能合约执行获客结算操作逻辑，得到结算数据并记录至所述公有链；所述获客数据包括所述结算数据。

可选的，所述智能合约还包括仲裁操作逻辑；所述方法还包括：接收第二业务使用方发起的仲裁请求；所述仲裁请求至少包括：所述第二标识和第四标识；所述第四标识为所述第二业务使用方的区块链地址；触发执行所述仲裁操作逻辑，得到仲裁结果数据并记录至所述公有链；所述获客数据包括所述仲裁结果数据。

可选的，所述结算条件包括：新客户奖励的有效期，以及，针对每一新客户向渠道提供方分配的支付数量；所述执行所述智能合约的获客结算操作逻辑包括：判断所述第一业务使用方是否是新客户；若所述第一业务使用方是新客户，进行新客奖励校验；所述新客奖励校验包括：校验当前时刻是否位于所述有效期内；在所述新客奖励校验通过后，校验所述智能合约的获客协议是否有效；若有效，根据所述支付数量向所述第一标识分配虚拟货币；所述结算数据至少包括所述第一标识、所述第二标识、所述第三标识，以及，本次获客结算交易为所述第一标识所分配的虚拟货币的数量。

可选的，所述获客协议还包括：新客奖励数量；所述新客奖励数量包括：为新客户分配的支付数量；所述执行所述智能合约的获客结算操作逻辑还包括：在所述新客奖励校验通过后，根据所述新客奖励数量向所述第三标识分配虚拟货币；所述获客数据还包括：所述第二标识、所述第三标识，以及，本次获客结算交易为所述第三标识分配的虚拟货币的数量。

可选的，所述执行所述智能合约的仲裁操作逻辑包括：在裁定所述业务提供方针对所述第四标识漏分配虚拟货币后，向所述业务提供方的服务器发送通知消息；所述通知消息至少包括：时限；所述通知消息用于通知所述业务提供方在所述时限内发起新客奖励操作以向所述第四标识分配虚拟货币；在裁定符合代分配条件时，根据所述新客奖励数量向所述第四标识分配虚拟货币；所述仲裁结果数据包括：第一裁定结果和所述通知消息，或者，第二裁定结果和相应的代分配结算数据；其中，所述第一裁定结果包括：表征所述业务提供方漏执行针对所述第二业务使用方的新客奖励操作的信息；所述第二裁定结果包括：表征所述代分配条件被满足的信息；所述代分配结算数据包括：所述第二标识、所述第四标识，以及，本次仲裁为所述第四标识分配的虚拟货币的数量。

可选的，所述执行所述智能合约的仲裁操作逻辑包括：在裁定满足暂停条件时，将所述获客协议设置为无效；所述仲裁结果数据还包括：表征所述暂停条件被满足的信息。

可选的，所述智能合约包括注册操作逻辑；所述注册操作逻辑用于渠道提供方和业务提供方向所述公有链注册，在所述公有链上保存注册信息。

可选的，所述智能合约包括获客协议签署操作逻辑；在接收获客结算交易请求之前，所述方法还包括：接收渠道提供方或业务提供方的获客协议发起请求，在所述公有链上发起获客协议；接收获客协议签署确认消息；所述获客协议签署确认消息包括：签名；在所述渠道提供方和业务提供方均提交获客协议签署确认消息后，所述获客协议生效。

一种获客数据处理节点，用于维护公有链，所述公有链用于存储获客数据；所述公有链包括智能合约；所述智能合约至少包括：签署生效的获客协议和相应的获客结算操作逻辑；所述获客协议包括：签署方的注册信息以及结算条件；所述签署方包括：渠道提供方和业务提供方；所述注册信息至少包括使用者标识；其中，所述渠道提供方的服务器用于向业务使用方提供访问渠道，业务使用方通过所述访问渠道访问所述业务提供方的服务器；所述业务提供方的服务器用于：在业务使用方通过预设校验后，向所述公有链发起获客结算交易；

所述节点包括：

通信单元，用于：接收获客结算交易请求；其中，所述获客结算交易请求至少指定了：第一标识、第二标识和第三标识；所述第一标识为渠道提供方的使用者标识；所述第二标识为业务提供方的使用者标识；所述第三标识为第一业务使用方的区块链地址；

结算单元，用于：

触发所述智能合约执行获客结算操作逻辑，得到结算数据并记录至所述公有链；所述获客数据包括所述结算数据。

可选的，所述智能合约还包括仲裁操作逻辑；所述节点还包括仲裁单元；

所述通信单元还用于：接收第二业务使用方发起的仲裁请求；所述仲裁请求至少包括：所述第二标识和第四标识；所述第四标识为所述第二业务使用方的区块链地址；所述仲裁单元用于：触发执行所述智能合约的仲裁操作逻辑，得到仲裁结果数据并记录至所述公有链；所述获客数据包括所述仲裁结果数据。

可见，在本发明实施例中，业务使用方通过访问渠道访问业务提供方的服务器后，若业务提供方的服务器完成了预设操作，会向公有链发起获客结算交易。公有链指全世界任何人都可读取、发送交易且交易能获得有效确认的、也可参与其中共识过程的区块链。本发明实施例将区块链应用于获客实时结算场景，通过公有链的智能合约自动完成获客结算交易，并将结算数据记录至公有链上，达到实时结算的效果。这样，可将渠道提供方、业务提供方、客户都包含到获客实时结算场景中。并且，基于区块链公开透明、不可篡改等特点，可解决数据的不透明问题，提供数据可靠性，进而减少合作双方的合作纠纷，提高获客效果。

附图说明

图1为现有的渠道获客方式示例性流程；

图2为本发明实施例提供的公有链网络的示意图；

图3为本发明实施例提供的新客奖励的示例性应用场景；

图4为本发明实施例提供的注册过程的示例性流程；

图5为本发明实施例提供的协议签署过程的示例性流程；

图6为本发明实施例提供的获客数据处理方法的一种示例性交互流程；

图7为本发明实施例提供的获客仲裁的一种示例性交互流程；

图8为本发明实施例提供的获客数据处理节点的一种示例性结构；

图9为本发明实施例提供的获客数据处理节点的一种硬件结构示意图。

具体实施方式

本发明实施例提供了获客数据处理方法与节点，以解决现有获客流程中数据不透明、不可靠的问题。

本发明技术方案的核心是将公有链应用于获客结算场景中，基于公有链的智能合约完成获客实时结算。

公有链是由公有链网络进行维护的。请参见图2，公有链网络包括多个可进行P2P通讯的区块链节点(也即本申请要求保护的获客数据处理节点)。P2P是指参与网络的计算机彼此相等。

一个区块链节点可以随时接入一个公有链的网络或退出。区块链节点通常是指下载了公有链程序，以参与对等网络的计算机。

下面介绍公有链，公有链包括至少一个区块，区块是存储单元，记录了一定时间内各个区块链节点全部的交流信息。各个区块之间通过随机散列(也称哈希算法)实现链接，后一个区块包含前一个区块的哈希值，随着信息交流的扩大，一个区块与一个区块相继接续，形成的结果就叫区块链。

智能合约(Smart contract)则是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约允许在没有第三方的情况下进行可信交易，这些交易可追踪且不可逆转。

智能合约可视为公有链程序的一个组件。智能合约可依需要进行自主开发。开发完成后的智能合约的部署和生效是在一个区块里作为交易提交的。所有接入公有链网络的用户都可以看到该智能合约。

在正常使用中，智能合约至少包括：签署生效的获客协议和相应的获客结算操作逻辑。

请参见下表1，本发明实施例所采用的智能合约示例性的包括但不限如下操作逻辑(功能)：

该智能合约的功能包括：

表1

从时序上讲，渠道提供方和业务提供方分别需要在公有链上注册，然后签署获客协议，之后获客协议正式生效，此后，可基于智能合约进行获客结算交易。

此外，还可在公有链上设置仲裁委员会，仲裁委员会将监督日常获客行为，处理可能发生的企业获客作恶行为。

仲裁委员会包括一个或多个仲裁成员，每一仲裁成员对应一个用户账号。例如，可将某管理员账号设置为仲裁成员，登陆该账号，就可以作为仲裁者去进行仲裁。

相应的，上述智能合约还可包括仲裁操作逻辑，或者，可将仲裁操作逻辑设计为一个独立于智能合约的组件，部署于公有链上。

因此，在一个示例中，因此，获客数据处理节点可分为两类：一类是运行智能合约的节点，一类是运行仲裁操作逻辑的节点。当然，也可由同一节点运行智能合约和仲裁操作逻辑。

在另一个示例中，若获客数据处理节点是区块链节点，则同时包含智能合约逻辑和仲裁操作逻辑。在使用时，可只专门对某一特定节点发送一种请求(例如获客结算请求或仲裁请求)。

需要说明的是，渠道提供方、业务提供方、客户提供方都对应有账户，使用者可通过其他设备(例如手机、服务器等)，以某一账户与获客数据处理节点通信，以达到访问公有链、发起某项交易的目的。

图3示出了上述获客数据处理节点(以A至E表示有多个获客数据处理节点)和公有链的一种示例性应用场景(新客奖励应用场景)：

步骤1：渠道商C向客户A提供跳转链接(即访问渠道)；

步骤2：客户A访问链接，跳转至企业B的网站；

步骤3：企业B校验客户A是否为新客户；若是，进入步骤4；

步骤4：触发结算合约(也即智能合约)；

步骤5：结算合约向客户A发送新客奖励(新客奖励可以是token)，并记录至公有链；

token是区块链上的货币，可以用它与代金券、礼券进行兑换。

步骤6：结算合约向渠道商C结算(例如向渠道商C分配token)，并记录至公有链。

在需要仲裁时，还可由仲裁委员会中的成员向公有链发起仲裁交易(步骤7)。

下面将从技术角度介绍如何实现基于公有链进行获客结算。

从时序上，可包括准备阶段(又可细化为注册阶段和协议签署阶段)、获客阶段，在需要仲裁时，还可包括仲裁阶段。

一，注册阶段：

请参见图4，注册阶段示例性的包括如下流程：

S401：建立一条用于存储获客数据的公有链。

具体的，可由某渠道提供方或业务提供方申请建立一条公有链，公有链会有分配ID。

需要说明的是，以业务提供方申请建立公有链为例，若业务提供方可提供多项业务，其可针对每一项业务建立一条公有链，也可有使用一条公有链对应多项业务的获客结算。

S402：准备智能合约。

可由某渠道提供方或业务提供方准备智能合约，并上传至公有链。

S403：业务提供方进行注册。

渠道提供方、业务提供方均需进行注册，才可进行后续的协议签署、发起交易等。

具体的，前述提及，智能合约包括注册操作逻辑，可通过注册操作逻辑完成渠道提供方和业务提供方在公有链上的注册，保存注册信息，以及进行注册信息查询、更新等。

业务提供方(例如企业、商家)在公有链上的注册信息包括但不限于：

a，业务提供方信息(包括名称、基本信息)。

业务提供方信息相当于公示，各方都可以在公有链上检索到业务提供方的信息，如果需要，还可以增加审核环节。

在用户注册时，会为用户分配区块链地址，区块链地址由账户私钥计算，区块链地址可作为使用者标识。业务提供方信息中也可包括企业的使用者标识。

b，具体业务的业务信息。

具体业务是指企业内部需要获客的具体业务；需要说明的是，业务提供方与具体业务可为一对多的关系，也即，一个业务提供方可拥有多个具体业务。

c，获客方式信息。

获客方式是指企业BI获客的具体方式，例如，最常见的线上链接导流，获客方式信息包括URL、有效时间等信息。

BI与获客方式之间可为一对一，或一对多的关系(也即，同一BI可使用多种获客方式)

d，初始化信息。

以新客奖励应用场景为例，初始化信息可包括BI、新客奖励数量(例如对每个新客奖励的token数量)、新客奖励的有效期(其限定在某个时间范围内，客户可以获得奖励)等信息。

具体的，可将初始化信息进行签名，然后提交到公有链上，任何接入该公有链的用户可以查看到该信息。

S404：渠道提供方注册。

渠道提供方的注册信息包括：渠道提供方信息(包括名称、基本信息，例如公司信息、联系方式等)，以及，渠道提供方支持的获客方式信息。

此外，还可在公有链上事先指定仲裁委员会的成员。

步骤S402-S404执行顺序并不限定。

二，协议签署阶段：

前述提及，智能合约包括获客协议签署操作逻辑，可通过执行获客协议签署操作逻辑，完成渠道提供方和业务提供方在公有链上的获客协议发起，签署获客协议、查询获客协议等。

请参见图5，协议签署阶段示例性地包括如下步骤：

S501：接收渠道提供方或业务提供方的获客协议发起请求，在公有链上发起获客协议。

在发起获客协议发起请求时，在公有链上就可以看到获客协议。

S502：接收返回信息。

返回信息至少包括表征是否签署获客协议的信息。例如，yes或no。

若是no，则表示不同意签署，则不会进入后续步骤。

S502是协议过程，可以线下完成。也可在公有链上完成。

在一个示例中，若为yes，则返回信息还可进一步包括：获客方式信息和获客协议有效期。

在另一个示例中，若为yes，则返回信息还可进一步包括：结算条件。

在新客奖励应用场景下，结算条件示例性的包括：新客户奖励的有效期，以及，针对每一新客户向渠道提供方分配的支付数量(例如token数)。

在返回信息存在获客方式信息、获客协议有效期和结算条件中的任一种时，可使用返回信息中携带的信息去更新获客协议。

当然，在其他实施例中，结算条件、获客方式信息和获客协议有效期等也可以发起获客协议时提出，写在获客协议中，而不在协商过程中提出。

返回信息可由渠道提供方或业务提供方上传至公有链的区块。

在其他实施例中，也可不包含S502。

S503：接收获客协议签署确认消息。

获客协议签署确认消息可包括签署方的签名信息。

以渠道提供方为例，其提交的获客协议签署确认消息中，有渠道提供方的签名信息。

获客协议签署确认消息也会记录至公有链的区块，但一般与协商请求不在一个区块中。

当两方(渠道提供方和业务提供方)都提交获客协议签署确认消息后，双方正式达成获客协议，获客协议生效。渠道提供方开始在线上通过广告形式进行获客。

三，获客阶段

图6示出了由上述获客数据处理节点所参与的获客数据处理方法的一种示例性交互流程，包括：

S1：渠道提供方的服务器向某客户A(可称为第一业务使用方)提供访问渠道。

举例来讲，渠道提供方向客户A展示广告，广告中包含访问渠道。客户点击广告可跳转至业务提供方(商家)的企业APP/网站。

需要说明的是，第一、第二是用于区分业务使用方。

S2：第一业务使用方通过访问渠道访问业务提供方的服务器。

具体的，第一业务使用方在通过访问渠道(例如链接)跳转至业务提供方的企业APP/网站，并附上第一业务使用方的区块链地址和签名。

附上签名是为了确认发起方与区块链地址是否匹配。

第一业务使用方所使用的设备可自行生成区块链地址，也可由业务方生成托管。

S3：业务提供方的服务器对第一业务使用方执行预设校验，若通过，进入S4，否则，退出。

具体的，业务提供方服务器可校验第一业务使用方的区块链地址是否准确以及签名是否正确，若不正确，提示重新提交。

区块链地址和签名校验通过后，可验证第一业务使用方是否是新客户，若不是新客户或不符合事先定义的新客规则(新客规则可规定新客活动的时间范围，例如，新客活动只在某个时间段内有效)，流程结束，否则进入下一步骤。

在其他实施例中，也可先验证第一业务使用方是否是新客，若是新客，再对区域链地址和签名进行校验。二者都通过才进入S4。

S4：业务提供方的服务器向公有链发起获客结算交易请求。

其中，获客结算交易请求至少指定了：第一标识、第二标识和第三标识；第一标识为渠道提供方的使用者标识；第二标识为业务提供方的使用者标识；第三标识为第一业务使用方的区块链地址。

S5：获客数据处理节点触发智能合约执行获客结算操作逻辑，得到结算数据并记录至公有链。

在本实施例中，前述提及的获客数据包括本次获客结算交易的结算数据。

在一个示例中，在新客奖励应用场景下，前述提及的结算条件可包括：新客户奖励的有效期，针对每一新客户向渠道提供方分配的支付数量(例如token数)。

则相应的，步骤S5可细化包括：

步骤51：(智能合约)判断第一业务使用方是否是新客户；若不是，则退出，否则执行下一步骤；

步骤52：若第一业务使用方是新客户，进行新客奖励校验。

具体的，新客奖励校验可包括：校验当前时刻是否位于新客户奖励的有效期内。

步骤53：在新客奖励校验通过后，校验获客协议是否有效。

获客协议也有自己的有效期，因此，在本步骤中会校验当前时刻是否位于获客协议的有效期内。

步骤54：若(获客协议)有效，根据结算条件中规定的支付数量向第一标识的区块链地址分配虚拟货币，并记录至公有链。

举例来讲，假定结算条件规定的token数量为2，则向渠道提供方的区块链地址分配2份token，即转帐。

在本示例中，记录至公有链的结算数据可进一步包括：第一标识、第二标识、第三标识，以及，本次获客结算交易为第一标识所分配的虚拟货币的数量。

此外，在本发明其他实施例中，也可基于公有链向新客户发送新客奖励。

则上述获客协议还包括：新客奖励数量；新客奖励数量包括：为新客户分配的支付数量。

则仍请参见图6，上述步骤S5还可包括如下步骤：

S55：在新客奖励校验通过后，根据新客奖励数量向第一业务使用者(也即第三标识)分配虚拟货币，并记录至公有链；

举例来讲，假定结算条件规定的token数量为1，则向第一业务使用方的区块链地址(第三标识)分配1份token。

步骤S55中分配的虚拟货币可简称为新客激励。

完成本步骤后，记录至公有链的获客数据还可包括：第二标识、第三标识，以及，为第三标识分配的虚拟货币的数量。

后续可以随时查询获客数据。

可见，在本发明实施例中，业务使用方通过访问渠道访问业务提供方的服务器后，若业务提供方的服务器完成了预设操作，会向公有链发起获客结算交易。公有链指全世界任何人都可读取、发送交易且交易能获得有效确认的、也可参与其中共识过程的区块链。本发明实施例将区块链应用于获客实时结算场景，通过公有链的智能合约自动完成获客结算交易，并将结算数据记录至公有链上，达到实时结算的效果。这样，可将渠道提供方、业务提供方、客户都包含到获客实时结算场景中。并且，基于区块链公开透明、不可篡改等特点，可解决数据的不透明问题，提供数据可靠性，进而减少合作双方的合作纠纷，提高获客效果。

四，获客仲裁：

考虑下述情况：业务提供方未将新客户的信息上传至区块链上，导致新客并未能收到新客激励。因此，可引入仲裁委员会进行获客监督。

业务提供方缴纳一定量的保证金(可以是token形式)给仲裁委员会，保证金由仲裁委员会保管。

保证金也保存在公有链上。

请参见图7，获客仲裁的一种示例性交互流程包括：

S71：当客户B未收到预期的新客奖励，将向仲裁委员会发起仲裁请求。

具体的，未收到新客奖励的新客户(可称为第二业务使用方)可向仲裁节点/获客数据处理节点发起的仲裁请求。

其中，仲裁请求可至少包括：第二标识(表征业务提供方)和第四标识，第四标识为第二业务使用方的区块链地址，用于表征第二业务使用方。

仲裁节点/获客数据处理节点可将仲裁请求分发至仲裁委员会的各个成员的账户上。

S72：仲裁委员会进行取证调查。

该步骤可线下进行。

S73：触发执行智能合约的仲裁操作逻辑，得到仲裁结果数据并记录至公有链。

前述提及的，获客数据还可包括仲裁结果数据。

现实中，商家可能因不同的原因而未发送新客奖励，因此，步骤S73可进一步进行如下细化：

S731：在裁定业务提供方针对第四标识漏分配虚拟货币后，向业务提供方的服务器发送通知消息。

具体的，若裁定业务提供方属于漏发新客奖励(例如token)的情况，可发送通知消息。

上述通知消息至少包括：时限。

通知消息用于通知业务提供方在该时限内发起新客奖励操作以向第四标识分配虚拟货币。

业务提供方可向公有链发起新客奖励交易请求或获客结算交易请求，触发智能合约执行前述步骤51、52、53、55，或执行前述步骤51-55。

若执行步骤S731，则仲裁结果数据可包括：第一裁定结果和上述通知消息，第一裁定结果包括：表征业务提供方漏执行针对第二业务使用方的新客奖励操作的信息。

S732：在裁定符合代分配条件时，根据新客奖励数量向第四标识分配虚拟货币；

其中，代分配条件可示例性的包括但不限于：业务提供方的漏发新客奖励的行为属于作恶行为，或者，业务提供方未在时限内为第二业务使用者补足新客激励。

前述提及了业务提供方向仲裁委员缴纳了保证金，可从保证金中代扣相应数量的虚拟货币给第二业务使用者。

若执行步骤S732，则仲裁结果数据可包括：第二裁定结果和相应的代分配结算数据；

其中，第二裁定结果包括：表征代分配条件被满足的信息；而代分配结算数据包括：第二标识、第四标识，以及，本次仲裁为第四标识分配的虚拟货币的数量。

此外，作为惩罚，还可并永久扣除一部分保证金。

则仲裁结果数据还可包括：被扣除的虚拟货币的数量。

在本发明其他实施例中，还可执行如下步骤：

S733：在裁定满足暂停条件时，将获客协议设置为无效。

在执行完本步骤后，仲裁结果数据还可包括：表征暂停条件被满足的信息。各参与方包括渠道商、用户可以及时感知获客结算暂停，渠道提供方不再提供导流服务。

示例性的，暂停条件包括但不限于：保证金低于预设阈值或者裁定业务提供方有严重失信行为。

综上，本发明将区块链应用于获客实时结算场景，将企业、渠道商、用户都包含到获客场景中，通过智能合约使获客流程更加自动化、规范化，达到实时结算的效果，提升企业与渠道商之间的结算效率，减少获客流程结算数据不一致导致的商业纠纷。对于客户而言，企业将新客奖励明确写入区块链，利用区块链不可篡改的特性，让客户可以如预期获得新客奖励，区块链记录也是新客维权的手段，提高客户对企业的信任，促进企业获客的效果。此外，区块链上留存的数据真实可靠，为企业、渠道商后续数据查询、数据分析提供坚实的基础。

下面介绍获客数据处理节点。

图8示出了上述获客数据处理节点的一种示例性结构，包括：

通信单元81，用于：接收获客结算交易请求；其中，获客结算交易请求至少指定了：第一标识、第二标识和第三标识；第一标识为渠道提供方的使用者标识；第二标识为业务提供方的使用者标识；第三标识为第一业务使用方的区块链地址；

结算单元82，用于：

触发智能合约执行获客结算操作逻辑，得到结算数据并记录至公有链；获客数据包括结算数据。

具体细节请参见本文前述记载，在此不作赘述。

在本发明其他实施例中，上述智能合约还包括仲裁操作逻辑；

相应的，仍请参见图8，上述节点还可包括仲裁单元83；

在仲裁阶段，通信单元81还可用于：接收第二业务使用方发起的仲裁请求；

其中，仲裁请求至少包括：第二标识和第四标识；第四标识为第二业务使用方的区块链地址；

仲裁单元83可用于：

触发执行智能合约的仲裁操作逻辑，得到仲裁结果数据并记录至公有链；获客数据包括仲裁结果数据。

具体细节请参见本文前述记载，在此不作赘述。

在本发明其他实施例中，上述智能合约包括注册操作逻辑；注册操作逻辑用于渠道提供方和业务提供方向公有链注册，在公有链上保存注册信息。

相应的，仍请参见图8，上述节点还可包括注册单元84，用于触发执行智能合约的注册操作逻辑，完成注册请求方的向公有链的注册，在公有链上保存注册信息。

在本发明其他实施例中，智能合约包括获客协议签署操作逻辑。

相应的，仍请参见图8，上节点还可包括签署单元85。用于触发执行智能合约的获客协议签署操作逻辑，完成如下操作：

接收渠道提供方或业务提供方的获客协议发起请求，在公有链上发布获客协议；

接收返回信息；返回信息至少包括表征是否签署获客协议的信息；

接收获客协议签署确认消息；获客协议签署确认消息包括：签名；

在渠道提供方和业务提供方均提交获客协议签署确认消息后，获客协议生效。

上述获客数据处理节点中的各模块可以软件或组件的形式部署于同一服务器(例如获客数据处理服务器)上，或者，上述获客数据处理节点所包含的各模块可分别为独立的服务器。

图9示出了上述实施例中获客数据处理节点的一种可能的硬件结构示意图，包括：总线、处理器1、存储器2、通信接口3、输入设备4和输出设备5。处理器1、存储器2、通信接口3、输入设备4和输出设备5通过总线相互连接。其中：

总线可包括一通路，在计算机系统各个部件之间传送信息。

处理器1可以是通用处理器，例如通用中央处理器(CPU)、网络处理器(NetworkProcessor，简称NP)、微处理器等，也可以是特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本发明方案程序执行的集成电路。还可以是数字信号处理器(DSP)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

存储器2中保存有执行本发明技术方案的程序或脚本，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。脚本则通常以文本(如ASCII)保存，只在被调用时进行解释或编译。

输入设备4可包括接收用户输入的数据和信息的节点，例如键盘、鼠标、摄像头、语音输入节点、触摸屏等。

输出设备5可包括允许输出信息给用户的节点，例如显示屏、扬声器等。

通信接口3可包括使用任何收发器一类的节点，以便与其他设备或通信网络通信，如以太网，无线接入网(RAN)，无线局域网(WLAN)等。

处理器1通过执行存储器2中所存放的程序以及调用其他设备，可实现上述实施例提供的各流程及方法。

此外，图9所示的获客数据处理节点中各单元的功能，可由前述的处理器1执行存储器2中所存放的程序以及调用其他设备实现。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及模型步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或模型的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、WD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种获客数据处理方法，其特征在于，基于用于存储获客数据的公有链，所述公有链包括智能合约；所述智能合约至少包括：签署生效的获客协议和相应的获客结算操作逻辑；所述获客协议包括：签署方的注册信息以及结算条件；所述签署方包括：渠道提供方和业务提供方；所述注册信息至少包括使用者标识；其中，所述渠道提供方的服务器用于向业务使用方提供访问渠道，业务使用方通过所述访问渠道访问所述业务提供方的服务器；所述业务提供方的服务器用于：在业务使用方通过预设校验后，向所述公有链发起获客结算交易；

所述方法包括：

接收获客结算交易请求；其中，所述获客结算交易请求至少指定了：第一标识、第二标识和第三标识；所述第一标识为渠道提供方的使用者标识；所述第二标识为业务提供方的使用者标识；所述第三标识为第一业务使用方的区块链地址；

触发所述智能合约执行获客结算操作逻辑，得到结算数据并记录至所述公有链；所述获客数据包括所述结算数据；

所述智能合约还包括仲裁操作逻辑，执行所述智能合约的仲裁操作逻辑包括：

在裁定所述业务提供方针对第四标识漏分配虚拟货币后，向所述业务提供方的服务器发送通知消息；所述通知消息至少包括：时限；所述通知消息用于通知所述业务提供方在所述时限内发起新客奖励操作以向所述第四标识分配虚拟货币；其中，所述第四标识为第二业务使用方的区块链地址；

在裁定符合代分配条件时，根据所述新客奖励数量向所述第四标识分配虚拟货币；

所述仲裁结果数据包括：第一裁定结果和所述通知消息，或者，第二裁定结果和相应的代分配结算数据；

其中，所述第一裁定结果包括：表征所述业务提供方漏执行针对所述第二业务使用方的新客奖励操作的信息；

所述第二裁定结果包括：表征所述代分配条件被满足的信息；所述代分配结算数据包括：所述第二标识、所述第四标识，以及，本次仲裁为所述第四标识分配的虚拟货币的数量。

2.如权利要求1所述的方法，其特征在于，所述智能合约还包括仲裁操作逻辑；

所述方法还包括：

接收第二业务使用方发起的仲裁请求；所述仲裁请求至少包括：所述第二标识和第四标识；

触发执行所述仲裁操作逻辑，得到仲裁结果数据并记录至所述公有链；所述获客数据包括所述仲裁结果数据。

3.如权利要求2所述的方法，其特征在于，

所述结算条件包括：新客户奖励的有效期，以及，针对每一新客户向渠道提供方分配的支付数量；

所述执行所述智能合约的获客结算操作逻辑包括：

判断所述第一业务使用方是否是新客户；

若所述第一业务使用方是新客户，进行新客奖励校验；所述新客奖励校验包括：校验当前时刻是否位于所述有效期内；

在所述新客奖励校验通过后，校验所述智能合约的获客协议是否有效；

若有效，根据所述支付数量向所述第一标识分配虚拟货币；所述结算数据至少包括所述第一标识、所述第二标识、所述第三标识，以及，本次获客结算交易为所述第一标识所分配的虚拟货币的数量。

4.如权利要求3所述的方法，其特征在于，所述获客协议还包括：新客奖励数量；所述新客奖励数量包括：为新客户分配的支付数量；

所述执行所述智能合约的获客结算操作逻辑还包括：

在所述新客奖励校验通过后，根据所述新客奖励数量向所述第三标识分配虚拟货币；

所述获客数据还包括：所述第二标识、所述第三标识，以及，本次获客结算交易为所述第三标识分配的虚拟货币的数量。

5.如权利要求4所述的方法，其特征在于，所述执行所述智能合约的仲裁操作逻辑包括：

在裁定满足暂停条件时，将所述获客协议设置为无效；

所述仲裁结果数据还包括：表征所述暂停条件被满足的信息。

6.如权利要求1所述的方法，其特征在于，

所述智能合约包括注册操作逻辑；

所述注册操作逻辑用于渠道提供方和业务提供方向所述公有链注册，在所述公有链上保存注册信息。

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

所述智能合约包括获客协议签署操作逻辑；

在接收获客结算交易请求之前，所述方法还包括：

接收渠道提供方或业务提供方的获客协议发起请求，在所述公有链上发起获客协议；

接收获客协议签署确认消息；所述获客协议签署确认消息包括：签名；

在所述渠道提供方和业务提供方均提交获客协议签署确认消息后，所述获客协议生效。

8.一种获客数据处理节点，其特征在于，用于维护公有链，所述公有链用于存储获客数据；所述公有链包括智能合约；所述智能合约至少包括：签署生效的获客协议和相应的获客结算操作逻辑；所述获客协议包括：签署方的注册信息以及结算条件；所述签署方包括：渠道提供方和业务提供方；所述注册信息至少包括使用者标识；其中，所述渠道提供方的服务器用于向业务使用方提供访问渠道，业务使用方通过所述访问渠道访问所述业务提供方的服务器；所述业务提供方的服务器用于：在业务使用方通过预设校验后，向所述公有链发起获客结算交易；

所述节点包括：

通信单元，用于：接收获客结算交易请求；其中，所述获客结算交易请求至少指定了：第一标识、第二标识和第三标识；所述第一标识为渠道提供方的使用者标识；所述第二标识为业务提供方的使用者标识；所述第三标识为第一业务使用方的区块链地址；

结算单元，用于：

触发所述智能合约执行获客结算操作逻辑，得到结算数据并记录至所述公有链；所述获客数据包括所述结算数据；

所述智能合约还包括仲裁操作逻辑，执行所述智能合约的仲裁操作逻辑包括：

在裁定所述业务提供方针对第四标识漏分配虚拟货币后，向所述业务提供方的服务器发送通知消息；所述通知消息至少包括：时限；所述通知消息用于通知所述业务提供方在所述时限内发起新客奖励操作以向所述第四标识分配虚拟货币；其中，所述第四标识为第二业务使用方的区块链地址；

在裁定符合代分配条件时，根据所述新客奖励数量向所述第四标识分配虚拟货币；

所述仲裁结果数据包括：第一裁定结果和所述通知消息，或者，第二裁定结果和相应的代分配结算数据；

其中，所述第一裁定结果包括：表征所述业务提供方漏执行针对所述第二业务使用方的新客奖励操作的信息；

所述第二裁定结果包括：表征所述代分配条件被满足的信息；所述代分配结算数据包括：所述第二标识、所述第四标识，以及，本次仲裁为所述第四标识分配的虚拟货币的数量。

9.如权利要求8所述的节点，其特征在于，

所述节点还包括仲裁单元；

所述通信单元还用于：接收第二业务使用方发起的仲裁请求；所述仲裁请求至少包括：所述第二标识和第四标识；所述仲裁单元用于：

触发执行所述智能合约的仲裁操作逻辑，得到仲裁结果数据并记录至所述公有链；所述获客数据包括所述仲裁结果数据。

Images