ID Mapping与用户唯一标识QAID

背景

您的Quick Audience数据池中可能有来源于多个渠道的同一个用户的数据，例如，导入的来自淘宝、微信小程序、自有App的订单数据表，导入的来自CRM的标签数据，埋点采集上报的自有App、小程序、Web或第三方系统的行为事件数据，上传的人群ID列表。

如何识别不同渠道中的同一个用户，使各渠道的数据形成合力，协助您的洞察决策，是V4版本着重解决的问题。

可以看出，用户标识很可能与企业一方ID、三方平台ID互相关联，设备ID很可能与埋点App的账号ID互相关联。无论数据来自于何种渠道，当不同类型的ID互相关联时，我们认为这些ID属于同一个用户。

ID Mapping就是我们依据这一思路实施的用户身份识别。

ID Mapping基本逻辑

总体来说，ID Mapping通过互相关联的ID数据进行用户身份识别、去重，最终为每个独立用户赋予Quick Audience中唯一身份标识QAID。

首先，我们来看一个最简单情况下的ID Mapping示例：

第一日：

• 导入的订单表包含一行：淘宝ID1、手机号1……

• App埋点采集上报的行为事件表含一行：IDFA1、手机号1……

则系统判定这些ID都属于同一个用户，并为这个用户赋予QAID1。

结果如下表所示。

ID Mapping中的ID冲突与解决办法

上述示例1中的每一种ID都仅有一个值，如果出现一种ID有多个值的情况呢？

此时，系统将依据ID的单值/多值性、优先级进行ID的合并和取舍。本章节中，为了表述方便，假设涉及的几种ID的单值/多值性、优先级如下表所示。

接下来我们看一些复杂情况下的ID Mapping示例。为了方便表示，所有表中的ID类型将按优先级从高到低排序。

第一日已有以下用户数据：

在此基础上，第二日：

• 导入的订单表包含一行：淘宝ID2、手机号1……

• App埋点采集上报的行为事件表含一行：IDFA2、手机号1……

在前述单值/多值规则、优先级规则下：

1. 由于IDFA为单值，IDFA2与IDFA1发生冲突，但由于IDFA优先级比手机号低且手机号一致，因此仍然判定为同一个用户。在默认的整体合并策略下，将仅保留创建时间最早的IDFA1。

2. 判定为同一个用户后，由于淘宝ID为多值，多个淘宝ID均得以保留。

结果如下表所示。

在上表中第二日用户数据的基础上，第三日：

• 导入的订单表包含一行：淘宝ID1、手机号2……

在前述单值/多值规则、优先级规则下：

• 虽然淘宝ID匹配，由于手机号为单值，手机号2与手机号1发生冲突，且手机号优先级比淘宝ID高，因此判定两个手机号归属于不同的用户。

结果如下表所示。

在上表中第三日用户数据的基础上，第四日：

• 上传的人群ID文件包含一行：淘宝ID1

在前述单值/多值规则、优先级规则下：

• QAID1、QAID2都有淘宝ID1，无法确认新上传的淘宝ID1属于哪个，因此最终判定为QAID1、QAID2以外的第三人。

结果如下表所示。

我们通过一个示例来了解QAID合并前后对使用用户数据的影响。

示例中，QAID4的IDFA3是新增数据，通过IDFA3进行合并。

合并前：

合并后：

说明：

• 合并前，若已通过创建人群等方式引用了QAID4，合并后，通过QAID4查询用户时，可以查询到QAID3的数据，因此，人群相关的营销任务等仍能正常进行。

• 合并前，视为两个不同用户，分别有一个淘宝ID；合并后，视为仅有一个用户，拥有两个淘宝ID。因此，营销任务中的用户数、ID数可能随时间变化，用户数与ID数可能不一致。

ID Mapping中的标签冲突与解决办法

ID Mapping过程中，除了可能发生上面介绍的ID冲突，还有可能发生标签冲突，即对于同一个标签表内的单值型标签，若原本独立的两个用户，由于新增的数据被识别为同一个用户，在合并数据时，仅能取其中一个值。

此时，系统将保留创建时间最早的标签值。

例如：原有QAID5、QAID6两个独立用户，如下表所示。

后续导入标签表时，QAID6新增手机号记录为手机号5，与QAID6手机号相同，且手机号优先级高，则ID Mapping时将QAID5、QAID6识别为同一个用户，最终保留的数据为：