Quick Audience在V4的表數據導入、事件數據上報等流程中引入自動的ID Mapping環節，通過ID Mapping實現跨來源渠道、跨ID類型的用戶身份識別、用戶數據拉通。
背景
您的Quick Audience數據池中可能有來源于多個渠道的同一個用戶的數據，例如，導入的來自淘寶、微信小程序、自有App的訂單數據表，導入的來自CRM的標簽數據，埋點采集上報的自有App、小程序、Web或第三方系統的行為事件數據，上傳的人群ID列表。
如何識別不同渠道中的同一個用戶，使各渠道的數據形成合力，協助您的洞察決策，是V4版本著重解決的問題。
ID分類
了解不同渠道的常見注冊、登錄流程后，我們發現部分ID類型互相關聯，可以對用戶身份的識別起到穿針引線的作用。
用戶ID大致可以分為四類：
用戶標識：本質上能夠代表一個用戶，在用戶注冊三方平臺、企業一方賬號時可能需要填寫，例如：手機號碼、電子郵箱等。
設備ID：電子設備自帶的ID，通常通過App埋點采集，例如：設備MAC地址、手機IMEI、安卓設備IMSI、OAID、蘋果設備IDFA等，并非與人本身綁定。
企業一方ID：由企業一方的業務系統為用戶生成的ID，例如：企業一方CRM的會員ID。在Quick Audience中，會員ID可以錄入為OneID類型。
三方平臺ID：用戶在三方平臺里的ID，例如：微信UnionID、OpenID、淘寶ID、淘寶昵稱、支付寶ID、微博ID等。在某些情況下，用戶會將三方平臺ID通過手機號等方式與企業一方ID進行綁定。
可以看出，用戶標識很可能與企業一方ID、三方平臺ID互相關聯，設備ID很可能與埋點App的賬號ID互相關聯。無論數據來自于何種渠道，當不同類型的ID互相關聯時，我們認為這些ID屬于同一個用戶。
ID Mapping就是我們依據這一思路實施的用戶身份識別。
ID Mapping基本邏輯
總體來說，ID Mapping通過互相關聯的ID數據進行用戶身份識別、去重，最終為每個獨立用戶賦予Quick Audience中唯一身份標識QAID。
QAID是用戶通過ID Mapping獲得的唯一身份標識。在后續操作中，將使用QAID代表用戶，當需要使用、推送其他ID類型、標簽等數據時，將根據QAID匹配出該用戶的所有ID類型、數據。
如遇ID已被加密，ID Mapping過程中：
對于已被AES加密的ID，將先進行解密，得到未加密狀態的ID。
如遇已被MD5/SHA256加密的ID，將對同類型ID的其他未被加密ID進行同樣的加密，使所有用于比對的ID均處于相同的加密狀態。
首先，我們來看一個最簡單情況下的ID Mapping示例：
示例1：同一手機號關聯多種ID
第一日：
導入的訂單表包含一行：淘寶ID1、手機號1……
App埋點采集上報的行為事件表含一行：IDFA1、手機號1……
則系統判定這些ID都屬于同一個用戶，并為這個用戶賦予QAID1。
結果如下表所示。
QAID | 手機號 | 淘寶ID | IDFA |
QAID1 | 手機號1 | 淘寶ID1 | IDFA1 |
ID Mapping中的ID沖突與解決辦法
上述示例1中的每一種ID都僅有一個值，如果出現一種ID有多個值的情況呢？
此時，系統將依據ID的單值/多值性、優先級進行ID的合并和取舍。本章節中，為了表述方便，假設涉及的幾種ID的單值/多值性、優先級如下表所示。
下表中僅為假設，實際的系統預置ID的默認配置請查閱系統預置ID，并且支持您修改配置和自定義ID。
ID | 單值/多值 | 優先級 |
手機號碼 | 單值 | 1 |
淘寶ID | 多值 | 2 |
IDFA | 單值 | 3 |
單值/多值ID
單值ID：單個用戶的同一種單值ID僅能有一個值。
例如：按照上表，一個用戶僅能有一個手機號碼、一個IDFA。
若同一個ID關聯的某種單值ID有多個不同的值，就是發生了沖突，需要通過ID優先級判定是否將其視為同一個用戶，請參見下面的ID優先級說明。
若同一種單值ID的多個值被系統判定屬于同一個用戶，將僅能保留其中一個值，需要按照整體合并策略判斷保留哪一個值。您可以選擇整體合并策略，可選的策略有：
默認策略：保留創建時間最早的ID類型值。例如：昨日用戶A記錄IDFA1，今日用戶A記錄IDFA2，則系統將保留IDFA1。
保留更新時間最晚的ID類型值。例如：昨日用戶B記錄IDFA3，今日用戶B記錄IDFA4，則系統將保留IDFA4。
保留一段時間內出現頻次最高的ID類型值。例如：過去1個月導入的數據中，用戶C記錄IDFA5出現了20次，記錄IDFA6出現了10次，則系統將保留IDFA5。
多值ID：單個用戶的同一種多值ID可以有多個值。
例如：按照上表，一個用戶可以能有多個淘寶ID。
若同一種多值ID的多個值被系統判定屬于同一個用戶，將保留所有值。多值ID不會發生沖突。
ID優先級
若同一個ID關聯的單值ID發生沖突，需要依據ID優先級判定是否將其視為同一個用戶：
高優先級的單值ID發生沖突，低優先級的ID相同，則判定為不同的用戶。
高優先級的ID相同，低優先級的單值ID發生沖突，則判定為同一個用戶。
下面以手機號和IDFA為例：
關聯關系 | 預設條件 | 結論 |
同一個IDFA關聯了2個手機號。 |
| 2個手機號屬于不同的用戶。 |
同一個手機號關聯了2個IDFA。 | 2個IDFA均屬于同一個用戶，將按照整體合并策略舍棄其中一個，確保最終為單值。 |
接下來我們看一些復雜情況下的ID Mapping示例。為了方便表示，所有表中的ID類型將按優先級從高到低排序。
示例2：同一手機號關聯不同淘寶ID、不同IDFA
第一日已有以下用戶數據：
QAID | 手機號（單值） | 淘寶ID（多值） | IDFA（單值） |
QAID1 | 手機號1 | 淘寶ID1 | IDFA1 |
在此基礎上，第二日：
導入的訂單表包含一行：淘寶ID2、手機號1……
App埋點采集上報的行為事件表含一行：IDFA2、手機號1……
在前述單值/多值規則、優先級規則下：
由于IDFA為單值，IDFA2與IDFA1發生沖突，但由于IDFA優先級比手機號低且手機號一致，因此仍然判定為同一個用戶。在默認的整體合并策略下，將僅保留創建時間最早的IDFA1。
判定為同一個用戶后，由于淘寶ID為多值，多個淘寶ID均得以保留。
結果如下表所示。
QAID | 手機號（單值） | 淘寶ID（多值） | IDFA（單值） |
QAID1 | 手機號1 | 淘寶ID1, 淘寶ID2 | IDFA1 |
示例3：同一淘寶ID關聯不同手機號
在上表中第二日用戶數據的基礎上，第三日：
導入的訂單表包含一行：淘寶ID1、手機號2……
在前述單值/多值規則、優先級規則下：
雖然淘寶ID匹配，由于手機號為單值，手機號2與手機號1發生沖突，且手機號優先級比淘寶ID高，因此判定兩個手機號歸屬于不同的用戶。
結果如下表所示。
QAID | 手機號（單值） | 淘寶ID（多值） | IDFA（單值） |
QAID1 | 手機號1 | 淘寶ID1, 淘寶ID2 | IDFA1 |
QAID2（新用戶） | 手機號2 | 淘寶ID1 | - |
示例4：同一淘寶ID屬于不同用戶，再導入同一淘寶ID時判定為哪個用戶？
在上表中第三日用戶數據的基礎上，第四日：
上傳的人群ID文件包含一行：淘寶ID1
在前述單值/多值規則、優先級規則下：
QAID1、QAID2都有淘寶ID1，無法確認新上傳的淘寶ID1屬于哪個，因此最終判定為QAID1、QAID2以外的第三人。
結果如下表所示。
QAID | 手機號（單值） | 淘寶ID（多值） | IDFA（單值） |
QAID1 | 手機號1 | 淘寶ID1, 淘寶ID2 | IDFA1 |
QAID2 | 手機號2 | 淘寶ID1 | - |
QAID3（新用戶） | - | 淘寶ID1 | - |
示例5：合并QAID
我們通過一個示例來了解QAID合并前后對使用用戶數據的影響。
示例中，QAID4的IDFA3是新增數據，通過IDFA3進行合并。
合并前：
QAID | 淘寶ID（多值） | IDFA（單值） | 創建時間 |
QAID3 | 淘寶ID3 | IDFA3 | 2021.10.1 00:00:00 |
QAID4 | 淘寶ID4 | IDFA3 | 2021.10.2 00:00:00 |
合并后：
QAID | 淘寶ID（多值） | IDFA（單值） | 創建時間 |
QAID3（曾用QAID4） | 淘寶ID3, 淘寶ID4 | IDFA3 | 2021.10.1 00:00:00 |
說明：
合并前，若已通過創建人群等方式引用了QAID4，合并后，通過QAID4查詢用戶時，可以查詢到QAID3的數據，因此，人群相關的營銷任務等仍能正常進行。
合并前，視為兩個不同用戶，分別有一個淘寶ID；合并后，視為僅有一個用戶，擁有兩個淘寶ID。因此，營銷任務中的用戶數、ID數可能隨時間變化，用戶數與ID數可能不一致。
ID Mapping中的標簽沖突與解決辦法
ID Mapping過程中，除了可能發生上面介紹的ID沖突，還有可能發生標簽沖突，即對于同一個標簽表內的單值型標簽，若原本獨立的兩個用戶，由于新增的數據被識別為同一個用戶，在合并數據時，僅能取其中一個值。
此時，系統將保留創建時間最早的標簽值。
例如：原有QAID5、QAID6兩個獨立用戶，如下表所示。
QAID | 手機號（單值） | 淘寶ID（多值） | 標簽A（單值） | 創建時間 |
QAID5 | 手機號5 | 淘寶ID5 | a5 | 2021.10.3 00:00:00 |
QAID6 | - | 淘寶ID6 | a6 | 2021.10.4 00:00:00 |
后續導入標簽表時，QAID6新增手機號記錄為手機號5，與QAID5手機號相同，且手機號優先級高，則ID Mapping時將QAID5、QAID6識別為同一個用戶，最終保留的數據為：
QAID | 手機號（單值） | 淘寶ID（多值） | 標簽A | 創建時間 |
QAID5（曾用QAID6） | 手機號5 | 淘寶ID5, 淘寶ID6 | a5 | 2021.10.3 00:00:00 |