用户ID关联方法、系统及批式、流式数据处理方法

技术领域

本申请涉及互联网技术领域，特别是涉及一种用户ID关联方法、系统及批式数据处理方法、流式数据处理方法。

背景技术

随着数字化越来越兴起，消费者越来越多的行为能够被采集并数字化记录下来，例如：广告行为，APP行为，微信行为，线下消费行为等等。

但由于各领域本身的独立性，不同领域日志记录的消费者原始ID是不同的，例如：广告行为一般是基于IMEI/IDFA做消费者唯一识别符；微信行为一般基于open_id/union_id做消费者的识别符；购买行为一般基于会员号做唯一识别符。即在没有“用户ID关联”的情况下，企业主无法串联各领域的消费者数据，或者更准确的说，跨ID分析单个消费者的全路径行为，从而形成更加全面的洞察和策略。

但是，简单地将所有渠道的ID做“全关联打通”，在部分数据准确性较高地场景下会造成过度关联。例如，在同一台电脑通过浏览器登录两个会员账号，认为该两个会员账号关联同一个cookie，而将这两个会员账号认为是同一个人，显然是有不够精准的现象。“全关联”方式下，虽然会最大的增加用户ID关联，但也会极大增加错误关联，造成业务损失，具体包括：数据分析时，由于关联ID过度，造成分析的错误和异常；营销触达时，由于关联ID过度，造成触达浪费和消费者反感。而行业内经常使用的“图数据库”存在硬件成本高、维护成本高的难点。

基于此，我们需要一种更好的、符合业务逻辑的解决方案。

发明内容

本申请实施例提供了一种用户关联方法、系统和基于批式和流式计算的SuperID计算方法，解决用户ID过度关联及错误关联的问题，降低硬件成本及维护成本。

第一方面，本申请实施例提供了一种用户ID关联方法，包括：

数据获取步骤，用于获取待处理用户的多个原始ID及原始ID之间的绑定关系，并获取所述原始ID的唯一标识值，所述唯一标识值包括原始ID的类型IDType、原始ID对应的值IDValue；

SuperID定义步骤，用于定义一SuperID以标识通过至少一绑定关系互相连接的所述原始ID；

用户ID关联步骤，用于基于一绑定规则获取属于同一SuperID的所述原始ID，得到关联ID。

在其中一些实施例中，所述SuperID通过锚点取值，所述锚点为业务优先级最高的ID和/或时间最早的ID或记录。

在其中一些实施例中，所述绑定规则进一步包括：

规则一，每一所述原始ID只能直接绑定一个高优先级原始ID，以保证多个所述原始ID不会因为关联同一低级原始ID而关联；

规则二，每一所述原始ID不能直接绑定同一优先级多个所述原始ID；

规则三，当一所述原始ID拥有多个高优先级绑定关系时，取唯一有效绑定关系。

基于上述绑定规则，在多个冲突的关联关系中，选择业务上优先级最高的关联关系，保证关联的可靠性、提高关联准确性。

在其中一些实施例中，所述规则三中，取唯一有效绑定关系具体包括：

取所述多个高优先级绑定关系中相对高优先级的绑定关系；

若存在多个相同优先级的绑定关系，则取绑定关系产生时间最新的记录为唯一有效绑定关系。

基于上述绑定规则，保证每一SuperID对应的最高优先级ID数≤1，进一步提高SuperID绑定的可靠性。

在其中一些实施例中，所述SuperID按照一参数限制条件计算得到，所述参数限制进一步包括：

若一原始ID连接次数超过m，对原始ID两两之间绑定关系进行数据清洗；

若一SuperID对应的原始ID数量超过m，则重置所述原始ID并记录，其中，m的值根据实际应用场景可灵活设置。

第二方面，本申请实施例提供了一种用户ID关联系统，用于执行如上第一方面所述的用户ID关联方法，该系统包括：

数据获取模块，用于获取待处理用户的多个原始ID及原始ID之间的绑定关系，并获取所述原始ID的唯一标识值，所述唯一标识值包括原始ID的类型IDType、原始ID对应的值IDValue；

SuperID定义模块，用于定义一SuperID以标识通过至少一绑定关系互相连接的所述原始ID；

用户ID关联模块，用于基于一绑定规则获取属于同一SuperID的所述原始ID，得到关联ID。

第三方面，本申请实施例提供了一种批式数据处理方法，包括

数据获取步骤，用于通过一上游应用获取批量绑定关系，并将所述批量绑定关系传输至一SuperID服务；

SuperID获取步骤，用于通过所述SuperID服务执行如上述第一方面所述的用户ID关联方法，根据所述批量绑定关系进行计算并输出批量SuperID至一SuperID结果文件；

SuperID应用步骤，用于通过一下游应用获取所述SuperID结果文件，并基于所述SuperID结果文件进行数据处理。举例而非限制，所述下游应用基于所述SuperID结果文件进行数据库更新、数据治理、数据打通、数据分析或ID批量导出等。

第四方面，本申请实施例提供了一种流式数据处理方法，包括：

数据获取步骤，用于通过一上游应用获取流式绑定关系，并将所述流式绑定关系传输至一SuperID服务；可选的，所述流式绑定关系通过Kafka分布式流处理平台或应用程序接口API传输；

SuperID获取步骤，用于通过所述SuperID服务执行如上述第一方面所述的用户ID关联方法，根据所述流式绑定关系进行计算得到一SuperID结果文件，所述SuperID结果文件进一步包括：SuperID变化结果文件及SuperID全量结果文件；具体的，所述SuperID变化结果文件为所述SuperID服务基于所述上游应用的实时绑定关系，实时输出的；所述SuperID全量结果文件为所述SuperID服务以每日为频率基于绑定关系得到的。

SuperID应用步骤，用于通过一下游应用获取所述SuperID结果文件，并基于所述SuperID结果文件进行数据处理。举例而非限制，所述下游应用基于所述SuperID结果文件进行数据库更新。

值得注意的是，基于SuperID的批式数据处理方法常用语实时性需求不高但数据量较大的场景，基于SuperID的流式数据处理方法常用于实时性需求较高但数据量不大的场景。

第五方面，本申请实施例提供一种计算机设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述第一方面所述的用户ID关联方法。

第六方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上述第一方面所述的用户ID关联方法。

相比于相关技术，本申请实施例提供的用户关联方法、系统和基于批式和流式计算的SuperID计算方法，相较于现有技术，有效解决用户ID过度关联及错误关联的问题，提供一种关联可靠、准确地用户ID关联方案，相比于图数据库技术，有效降低硬件成本及维护成本，但又基于SuperID实现了图数据库同样的逻辑计算。

本申请的一个或多个实施例的细节在以下附图和描述中提出，以使本申请的其他特征、目的和优点更加简明易懂。

附图说明

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

图1是根据本申请实施例的用户ID关联方法的流程示意图；

图2是根据本申请实施例的用户ID关联系统的结构框图；

图3是根据本申请实施例的批式数据处理方法的流程示意图；

图4是根据本申请实施例的批式数据处理方法的原理示意图；

图5是根据本申请实施例的流式数据处理方法的流程示意图；

图6是根据本申请实施例的流式数据处理方法的原理示意图；

图7是根据本申请优选实施例的SuperID关联关系示意图；

图8是根据本申请优选实施例的另一SuperID关联关系示意图；

图9是根据本申请优选实施例的又一SuperID关联关系示意图；

图10是根据本申请实施例的流式数据处理方法分步骤的逻辑原理图。

附图说明：

101、数据获取模块；102、SuperID定义模块；103、用户ID关联模块。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行描述和说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本申请提供的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

显而易见地，下面描述中的附图仅仅是本申请的一些示例或实施例，对于本领域的普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图将本申请应用于其他类似情景。此外，还可以理解的是，虽然这种开发过程中所作出的努力可能是复杂并且冗长的，然而对于与本申请公开的内容相关的本领域的普通技术人员而言，在本申请揭露的技术内容的基础上进行的一些设计，制造或者生产等变更只是常规的技术手段，不应当理解为本申请公开的内容不充分。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域普通技术人员显式地和隐式地理解的是，本申请所描述的实施例在不冲突的情况下，可以与其它实施例相结合。

除非另作定义，本申请所涉及的技术术语或者科学术语应当为本申请所属技术领域内具有一般技能的人士所理解的通常意义。本申请所涉及的“一”、“一个”、“一种”、“该”等类似词语并不表示数量限制，可表示单数或复数。本申请所涉及的术语“包括”、“包含”、“具有”以及它们任何变形，意图在于覆盖不排他的包含；例如包含了一系列步骤或模块(单元)的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可以还包括没有列出的步骤或单元，或可以还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。本申请所涉及的“连接”、“相连”、“耦接”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电气的连接，不管是直接的还是间接的。本申请所涉及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。本申请所涉及的术语“第一”、“第二”、“第三”等仅仅是区别类似的对象，不代表针对对象的特定排序。

本实施例提供了一种用户ID关联方法。图1是根据本申请实施例的用户ID关联方法的流程示意图，如图1所示，该流程包括如下步骤：

数据获取步骤S101，用于获取待处理用户的多个原始ID及原始ID之间的绑定关系，并获取原始ID的唯一标识值，该唯一标识值包括原始ID的类型IDType、原始ID对应的值IDValue；

SuperID定义步骤S102，用于定义一SuperID以标识通过至少一绑定关系互相连接的原始ID，具体的，SuperID通过锚点取值，锚点为业务优先级最高的ID和/或时间最早的ID或记录，本实施例优先使用业务优先级最高的ID作为SuperID的取值锚点。

用户ID关联步骤S103，用于基于一绑定规则获取属于同一SuperID的原始ID，得到关联ID，其中，绑定规则进一步包括：

规则一，每一原始ID只能直接绑定一个高优先级原始ID，以保证多个原始ID不会因为关联同一低级原始ID而关联；

规则二，每一原始ID不能直接绑定同一优先级多个原始ID；

规则三，当一原始ID拥有多个高优先级绑定关系时，取唯一有效绑定关系。

基于上述绑定规则，在多个冲突的关联关系中，选择业务上优先级最高的关联关系，保证关联的可靠性、提高关联准确性。

在其中一些实施例中，上述规则三中，取唯一有效绑定关系具体包括：

取多个高优先级绑定关系中相对高优先级的绑定关系；

若存在多个相同优先级的绑定关系，则取绑定关系产生时间最新的记录为唯一有效绑定关系。

基于上述绑定规则，保证每一SuperID对应的最高优先级ID数≤1，保证SuperID绑定的可靠性。

在其中一些实施例中，SuperID按照一参数限制条件计算得到，参数限制进一步包括：

若一原始ID连接次数超过m，对原始ID两两之间绑定关系进行数据清洗；

若一SuperID对应的原始ID数量超过m，则重置原始ID并记录，其中，m的值根据实际应用场景可灵活设置。举例而非限制，设置m为5，此时，假设一上游浏览器通过作弊手段反复注册25个账号，则此时可根据m的值判断其中存在无效账号，相应的进行解绑处理。

下面通过优选实施例对本申请实施例进行描述和说明。

图7-9是根据本申请优选实施例的SuperID关联关系示意图，如图7所示，当我们获取绑定关系，

如1月1日，mobile 1与openid 1绑定：

CREATE(mobile_1:id{name:"mobile_1"}),(openid_1:id{name:"openid_1"})

CREATE(mobile_1)-[r1:binding{type:'default'}]->(openid_1)

则认为Mobie1和Openid 1属于同一SuperID A；得到图7所示关联关系。

再如1月2日，mobile 2与openid 2绑定：

CREATE(mobile_2:id{name:"mobile_2"}),(openid_2:id{name:"openid_2"})

CREATE(mobile_2)-[r2:binding{type:'default'}]->(openid_2)

新增mobile 2&openid 2属于SuperID B；更新得到的SuperID关联关系如图8所示。

若在1月3日的新增数据中，mobile 1与openid 2绑定：

MATCH(mobile_1:id{name:"mobile_1"}),(openid_2:id{name:"openid_2"})

CREATE(mobile_1)-[r3:binding{type:'default'}]->(openid_2)

则新增mobile 1、openid 1、mobile 2及openid 24个ID连接在一起，属于SuperIDA，更新得到最终的SuperID关联关系如图9所示。

值得注意的是，在实际应用中，可能一个绑定关系存在2个以上的ID，对于这种情况先将原始消息拆解为两两绑定关系进行处理。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例还提供了一种用户ID关联系统，该系统用于实现上述实施例及优选实施方式的用户ID关联方法，已经进行过说明的不再赘述。如以下所使用的，术语“模块”、“单元”、“子单元”等可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图2是根据本申请实施例的用户ID关联系统的结构框图，参考图2所示，该系统包括：

数据获取模块101，用于获取待处理用户的多个原始ID及原始ID之间的绑定关系，并获取原始ID的唯一标识值，唯一标识值包括原始ID的类型IDType、原始ID对应的值IDValue；

SuperID定义模块102，用于定义一SuperID以标识通过至少一绑定关系互相连接的原始ID；

用户ID关联模块103，用于基于一绑定规则获取属于同一SuperID的原始ID，得到关联ID。

需要说明的是，上述各个模块可以是功能模块也可以是程序模块，既可以通过软件来实现，也可以通过硬件来实现。对于通过硬件来实现的模块而言，上述各个模块可以位于同一处理器中；或者上述各个模块还可以按照任意组合的形式分别位于不同的处理器中。

本实施例还提供了一种基于SuperID的批式数据处理方法。图3是根据本申请实施例的批式数据处理方法的流程示意图，图4是根据本申请实施例的流式数据处理方法的原理示意图；结合参考图3、4所示，该计算方法包括如下步骤：

数据获取步骤S201，用于通过一上游应用获取批量绑定关系，并将批量绑定关系传输至一SuperID服务；

SuperID获取步骤S202，用于通过SuperID服务执行如上述实施例的用户ID关联方法，根据该批量绑定关系进行计算并输出批量SuperID至一SuperID结果文件；

SuperID应用步骤S203，用于通过一下游应用获取SuperID结果文件，并基于该SuperID结果文件进行数据处理。举例而非限制，下游应用基于所述SuperID结果文件进行数据库更新、数据治理、数据打通、数据分析或ID批量导出等。

本申请实施例还提供了一种基于的流式数据处理方法，图5是根据本申请实施例的流式数据处理方法的流程示意图，图6是根据本申请实施例的流式数据处理方法的原理示意图，结合参考图5、6所示，该计算方法包括：

数据获取步骤S301，用于通过一上游应用获取流式绑定关系，并将流式绑定关系传输至一SuperID服务；可选的，流式绑定关系通过Kafka分布式流处理平台或应用程序接口API传输；

SuperID获取步骤S302，用于通过SuperID服务执行如上述实施例的用户ID关联方法，根据该流式绑定关系进行计算得到一SuperID结果文件，SuperID结果文件进一步包括：SuperID变化结果文件及SuperID全量结果文件；具体的，SuperID变化结果文件为SuperID服务基于上游应用的实时绑定关系，实时输出的；SuperID全量结果文件为SuperID服务以每日为频率基于绑定关系得到的。

SuperID应用步骤S303，用于通过一下游应用获取SuperID结果文件，并基于SuperID结果文件进行数据处理。举例而非限制，下游应用基于SuperID结果文件进行数据库更新。

值得注意的是，基于SuperID的批式数据处理方法常用语实时性需求不高但数据量较大的场景，基于SuperID的流式数据处理方法常用于实时性需求较高但数据量不大的场景。

图10是根据本申请实施例的流式数据处理方法步骤S302的逻辑原理图，参考图10所示，该步骤的实现逻辑进一步包括：

首先，获取上游绑定数据mapping data；

然后，进行数据迭代，进一步包括：

A.将绑定数据的数据格式转化为：

(id，绑定关系详情mapping，绑定时间戳ts)；

B.判断该绑定关系是否为中心顶点center vertex，即基于当前绑定关系能否完备地计算出SuperID集合；

如果该绑定关系不是中心顶点center vertex，则继续采集绑定关系，计算SuperID集合；

如果该绑定关系不是中心顶点center vertex，则得到当前SuperID集合，迭代结束，进入下一步。

最后，基于id优先级，计算出该SuperID集合的唯一的SuperID值；判断当前计算结果是否对已有其他的SuperID集合graph有影响，

若有影响，则计算影响范围，并将所有受影响的SuperID集合的结果输出；

若没有影响，则直接输出当前SuperID集合的结果。

需要说明的是，在上述流程中或者附图的流程图中示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

另外，结合图1描述的本申请实施例用户ID关联方法可以由计算机设备来实现，计算机设备可以包括处理器以及存储有计算机程序指令的存储器。

具体地，上述处理器可以包括中央处理器(CPU)，或者特定集成电路(ApplicationSpecific Integrated Circuit，简称为ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

其中，存储器可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器可包括硬盘驱动器(Hard Disk Drive，简称为HDD)、软盘驱动器、固态驱动器(SolidState Drive，简称为SSD)、闪存、光盘、磁光盘、磁带或通用串行总线(Universal SerialBus，简称为USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器可在数据处理装置的内部或外部。在特定实施例中，存储器是非易失性(Non-Volatile)存储器。在特定实施例中，存储器包括只读存储器(Read-Only Memory，简称为ROM)和随机存取存储器(Random AccessMemory，简称为RAM)。在合适的情况下，该ROM可以是掩模编程的ROM、可编程ROM(Programmable Read-Only Memory，简称为PROM)、可擦除PROM(Erasable ProgrammableRead-Only Memory，简称为EPROM)、电可擦除PROM(Electrically Erasable ProgrammableRead-Only Memory，简称为EEPROM)、电可改写ROM(Electrically Alterable Read-OnlyMemory，简称为EAROM)或闪存(FLASH)或者两个或更多个以上这些的组合。在合适的情况下，该RAM可以是静态随机存取存储器(Static Random-Access Memory，简称为SRAM)或动态随机存取存储器(Dynamic Random Access Memory，简称为DRAM)，其中，DRAM可以是快速页模式动态随机存取存储器(Fast Page Mode Dynamic Random Access Memory，简称为FPMDRAM)、扩展数据输出动态随机存取存储器(Extended Date Out Dynamic RandomAccess Memory，简称为EDODRAM)、同步动态随机存取内存(Synchronous Dynamic Random-Access Memory，简称SDRAM)等。

存储器可以用来存储或者缓存需要处理和/或通信使用的各种数据文件，以及处理器所执行的可能的计算机程序指令。处理器通过读取并执行存储器中存储的计算机程序指令，以实现上述实施例中的任意一种用户ID关联方法。

另外，结合上述实施例中的用户ID关联方法，本申请实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种用户ID关联方法。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。