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 |