顧名思義我們知道ID Mapping 的操作對象是ID，目標或者是動作是Mapping，也就是說我們要做的事情其實就是想把不同平臺不同設備上的ID 打通，從而更好的去刻畫用戶，也就是說我們希望能打通用戶各個維度的數據，從而更好的去服務業務服務用戶。

通常公司有產品矩陣，而每個產品都有自己的注冊賬號產生的用戶ID。從公司全局，整合用戶表，用戶行為數據來看，確定不同產品的用戶ID是相同一個人非常重要, 選取合適的用戶標識對于提高用戶行為分析的準確性有非常大的影響，尤其是對用戶畫像、推薦、漏斗、留存、Session 等用戶相關的分析功能。

其實對于任何分析都是一樣的，如果我們不能準確標識一個用戶，那么我們的計算結果就沒有準確性可言，其實對于數據服務方而言，數據的準確性是我們的第一要務，我們寧愿不出數據，也不要出錯誤的數據。

ID Mapping 的背景

網絡身份證

假如沒有網絡身份證，那么每個商家(App)只能基于自己的賬號體系標識用戶，并記錄用戶的行為。而有了統一的網絡身份證之后，各個商家之間的數據就可以打通了，天貓不僅知道用戶A在淘寶系的購物數據，也能了解到該用戶在社交網絡的行為，以及旅游的喜好，等等。

在現實的數據中，由于，用戶可能使用各種各樣的設備，有著各種各樣的前端入口，甚至同一個用戶擁有多個設備以及使用多種前端入口，就會導致，日志數據中對同一個人，不同時間段所收集到的日志數據中，可能取到的標識個數、種類各不相同。

比如用戶可能使用各種各樣的設備，其次是不同設備有不同的操作系統，設置是軟件本身的版本也會影響我們對用戶的標識。

1. 手機、平板電腦、PC
2. 安卓手機、ios手機、winphone手機
3. 安卓系統有各種版本 ( 5.0 6.0 7.0 8.0 9.0 )
4. ios系統也有各種版本(3.x 4.x 5.x 6.x 7.x … 12.x )

存在的問題

1. 用戶設備的標識，沒辦法輕易定制一個規則來取某個作為唯一標識：
2. mac地址：手機網卡物理地址， 若干早期版本的ios，winphone，android可取到
3. imei(入網許可證序號)：安卓系統可取到，若干早期版本的ios，winphone可取到，運營商可取到
4. imsi(手機SIM卡序號)：安卓系統可取到，若干早期版本的ios，winphone可取到，運營商可取到
5. androidid ：安卓系統id
6. openuuid(app自己生成的序號) ：卸載重裝app就會變更
7. IDFA(廣告跟蹤碼)

擴展 IDFA

IDFA，英文全稱 Identifier for Advertising ，可以理解為廣告id，蘋果公司提供的用于追蹤用戶的廣告標識符，可以用來打通不同app之間的廣告。每個設備只有一個IDFA，不同APP在同一設備上獲取IDFA的結果是一樣的。

蘋果為了保護用戶隱私，早在2012年就不再允許其生態中的玩家獲取用戶的唯一標識符，但是商家在移動端打廣告的時候又希望能監控到每一次廣告投放的效果，因此，蘋果想出了折中的辦法，就是提供另外一套和硬件無關的標識符，用于給商家監測廣告效果，同時用戶可以在設置里改變這串字符，導致商家沒有辦法長期跟蹤用戶行為。這個就叫做廣告標識符(IDFA)，設置路徑是“設置->隱私->廣告->還原廣告標識符”，如下圖所示(iOS9)：

img

常見的標識

設備 ID

需要注意的是，設備 ID 并不一定是設備的唯一標識。例如 Web 端的 Cookies 有可能被清空(例如各種安全衛士)，而 iOS 端的 IDFV( Identifier For Vendor)在不同廠商的 App 間是不同的,而且重新安裝IDFV會被重置。

登錄 ID

登錄 ID 通常是業務數據庫里的主鍵或其它唯一標識。所以 登錄 ID，相對來說更精確更持久。但是，用戶在使用時不一定注冊或者登錄，而這個時候是沒有登錄 ID 的。

平臺 ID

其實這里的平臺指的一些大的生態系統，例如微信的生態、今日頭條等，我們很多依賴這些平臺的應用就可以使用用戶在這些平臺上的用戶標識作為標識,當然我們也可以在此基礎上為我們自己平臺上的用戶創建屬于本平臺的用戶表示，往往就是用戶的登錄ID。

方案詳解

因此，我們在進行任何數據接入之前，都應當先確定如何來標識用戶。下面會介紹幾種用戶標識方案的原理，以及幾種典型情況下的用戶標識方案。

方案一：只使用設備 ID

適合沒有用戶注冊體系，或者極少數用戶會進行多設備登錄的產品，如工具類產品、搜索引擎、部分電商等。這也是絕大多數其它數據分析產品唯一提供的方案。

局限性

• 同一用戶在不同設備使用會被認為不同的用戶，對后續的分析統計有影響。
• 不同用戶在相同設備使用會被認為是一個用戶，也對后續的分析統計有影響。
• 但如果用戶跨設備使用或者多用戶共用設備不是產品的常見場景的話，可以忽略上述問題。

方案二：關聯設備 ID 和登錄 ID(一對一)

僅使用 設備 ID 標識用戶雖然簡單，但是對于某些應用場景這種方式不夠準確，因此我們可以采用 設備 ID 和 登錄 ID 的方案，在一定程度上融合 設備 ID 和 登錄 ID，從而實現更準確的用戶追蹤。

成功關聯設備 ID 和登錄 ID 之后，用戶在該設備 ID 上或該登錄 ID 下的行為就會貫通，被認為是一個用戶 ID 發生的。在進行事件、漏斗、留存等用戶相關分析時也會算作一個用戶。

關聯設備 ID 和登錄 ID 的方法雖然實現了更準確的用戶追蹤，但是也會增加埋點接入的復雜度。所以一般來說，我們建議只有當同時滿足以下條件時，才考慮進行 ID 關聯：

• 需要貫通一個用戶在一個設備上注冊前后的行為。
• 需要貫通一個注冊用戶在不同設備上登錄之后的行為。

局限性

• 一個設備 ID 只能和一個登錄 ID 關聯，而事實上一臺設備可能有多個用戶使用。
• 一個登錄 ID 只能和一個設備 ID 關聯，而事實上一個用戶可能用一個登錄 ID 在多臺設備上登錄。

方案三：關聯設備 ID 和登錄 ID(多對一)

關聯設備 ID 和登錄 ID(一對一)雖然已經實現了跨設備的用戶貫通，但是對于某些應用場景還是不夠準確，因此這里提供一個新的關聯方案，支持一個登錄 ID 綁定多個設備 ID 的方案，從而實現更準確的用戶追蹤。

也就是跨端，其實這是非常常見的一種場景，例如你在PC 端和 移動端使用同一個產品。

一個用戶在多個設備上進行登錄是一種比較常見的場景，比如 Web 端和 App 端可能都需要進行登錄。支持一個登錄 ID 下關聯多設備 ID 之后，用戶在多設備下的行為就會貫通，被認為是一個ID 發生的。

局限性

• 一個設備 ID 只能和一個登錄 ID 關聯，而事實上一臺設備可能有多個用戶使用 多用戶使用同一個設備這個問題是無解的。
• 一個設備 ID 一旦跟某個登錄 ID 關聯或者一個登錄 ID 和一個設備 ID 關聯，就不能解除(自動解除)。而事實上，設備 ID 和登錄 ID 的動態關聯才應該是更合理的。

方案對比

將上述三個方案放到一起，可以明顯看到三種方案的區別，如下表所示：

• 方案一：僅使用設備 ID，不管用戶是誰，只要設備未變，設備ID 就不變，即使多人使用同一個設備，也會被識別為同一個用戶。
• 方案二：關聯設備 ID 和登錄 ID(一對一)，

當用戶換手機后，登錄賬號之后的行為與換手機之前的行為貫通了，但是在新設備上首次登錄之前的行為仍沒法貫通，仍被識別為新的用戶的行為。

當用戶把舊手機送給朋友之后，由于舊手機已被關聯到自己的登錄 ID 了，無法再與朋友的登錄 ID 關聯。后續使用這臺舊手機的用戶們，若不登錄就操作，則都會被識別為同一個用戶。

• 方案三：關聯設備 ID 和登錄 ID(多對一)

當用戶把舊手機送給朋友之后，由于舊手機已被關聯到自己的登錄 ID 了，無法再與朋友的登錄 ID 關聯。后續使用這臺舊手機的用戶們，若不登錄就操作，則都會被識別為同一個用戶)。

而事實上，舊手機上后續的匿名登錄很難識別到底是誰，可能歸為匿名登錄之前最近一次登錄的用戶會更合理一些。

其實，三種方案沒有對與錯，我們應該結合自己的業務場景以及埋點復雜度來選擇合適的方案。

總結

ID Mapping 就如同它的名字一樣，我們要做的就是將一系列的ID 關聯起來，一些列的ID 可能是用戶在不同平臺上的標識，也可能是用戶在不同設備上的標識，也可能是用戶在不同狀態下的標識，總之我們就是要將這一系列的ID 關聯起來，盡可能地將用戶的數據打通，從而提供更加全面準確的分析。

我們知道只有打破數據孤島數據才能發揮更大的價值，可能很多人都知道數據倉庫的數據集成環節其實就是為了打破數據孤島，其實我們的ID Mapping 也是為了打破數據孤島，其實ID Mapping 就兩個使命 1. 多端數據的識別;2. 多源數據的打通，其他的都是基于ID Mapping 的應用。