早晨起床的時候，發現自己尿分叉，我沒有多想，簡單洗洗就匆忙出門。路過早餐店，我看到師傅熟練的拉扯一小塊麵糰，拉至細長條，然後放入油鍋中，不一會功夫，一根屎黃色的油條便出鍋了，賣相不錯。我在想，小到炸屎黃色的油條，大到學習，其實都是一個熟能生巧的過程。
資料倉儲系列文章(持續更新)
- 數倉架構發展史
- 數倉建模方法論
- 數倉建模分層理論
- 數倉建模—寬表的設計
- 數倉建模—指標體系
- 資料倉儲之拉鍊表
- 數倉—資料整合
- 數倉—資料集市
- 數倉—商業智慧系統
- 數倉—埋點設計與管理
- 數倉—ID Mapping
- 數倉—OneID
- 數倉—AARRR海盜模型
- 數倉—匯流排矩陣
- 數倉—資料安全
- 數倉—資料質量
- 數倉—數倉建模和業務建模
關注
大資料技術派，回覆:資料，領取1024G資料。
顧名思義我們知道ID Mapping 的操作物件是ID，目標或者是動作是Mapping，也就是說我們要做的事情其實就是想把不同平臺不同裝置上的ID 打通，從而更好的去刻畫使用者，也就是說我們希望能打通使用者各個維度的資料，從而更好的去服務業務服務使用者
通常公司有產品矩陣，而每個產品都有自己的註冊賬號產生的使用者ID。從公司全域性，整合使用者表，使用者行為資料來看，確定不同產品的使用者ID是相同一個人非常重要, 選取合適的使用者標識對於提高使用者行為分析的準確性有非常大的影響，尤其是對使用者畫像、推薦、漏斗、留存、Session 等使用者相關的分析功能。
其實對於任何分析都是一樣的，如果我們不能準確標識一個使用者，那麼我們的計算結果就沒有準確性可言，其實對於資料服務方而言，資料的準確性是我們的第一要務，我們寧願不出資料，也不要出錯誤的資料。
ID Mapping 的背景
網路身份證
假如沒有網路身份證，那麼每個商家（App）只能基於自己的賬號體系標識使用者，並記錄使用者的行為。而有了統一的網路身份證之後，各個商家之間的資料就可以打通了，天貓不僅知道使用者A在淘寶系的購物資料，也能瞭解到該使用者在社交網路的行為，以及旅遊的喜好，等等。
在現實的資料中，由於，使用者可能使用各種各樣的裝置，有著各種各樣的前端入口，甚至同一個使用者擁有多個裝置以及使用多種前端入口，就會導致，日誌資料中對同一個人，不同時間段所收集到的日誌資料中，可能取到的標識個數、種類各不相同；
比如使用者可能使用各種各樣的裝置，其次是不同裝置有不同的作業系統，設定是軟體本身的版本也會影響我們對使用者的標識，
- 手機、平板電腦、PC
- 安卓手機、ios手機、winphone手機
- 安卓系統有各種版本 （ 5.0 6.0 7.0 8.0 9.0 ）
- ios系統也有各種版本（3.x 4.x 5.x 6.x 7.x … 12.x ）
存在的問題
- 使用者裝置的標識，沒辦法輕易定製一個規則來取某個作為唯一標識：
- mac地址：手機網路卡實體地址， 若干早期版本的ios，winphone，android可取到
- imei(入網許可證序號)：安卓系統可取到，若干早期版本的ios，winphone可取到，運營商可取到
- imsi(手機SIM卡序號)：安卓系統可取到，若干早期版本的ios，winphone可取到，運營商可取到
- androidid ：安卓系統id
- openuuid(app自己生成的序號) ：解除安裝重灌app就會變更
- IDFA(廣告跟蹤碼)
擴充套件 IDFA
IDFA，英文全稱 Identifier for Advertising ，可以理解為廣告id，蘋果公司提供的用於追蹤使用者的廣告識別符號，可以用來打通不同app之間的廣告。每個裝置只有一個IDFA，不同APP在同一裝置上獲取IDFA的結果是一樣的
蘋果為了保護使用者隱私，早在2012年就不再允許其生態中的玩家獲取使用者的唯一識別符號，但是商家在移動端打廣告的時候又希望能監控到每一次廣告投放的效果，因此，蘋果想出了折中的辦法，就是提供另外一套和硬體無關的識別符號，用於給商家監測廣告效果，同時使用者可以在設定裡改變這串字元，導致商家沒有辦法長期跟蹤使用者行為。這個就叫做廣告識別符號（IDFA），設定路徑是“設定->隱私->廣告->還原廣告識別符號”，如下圖所示（iOS9）
常見的標識
裝置 ID
需要注意的是，裝置 ID 並不一定是裝置的唯一標識。例如 Web 端的 Cookies 有可能被清空（例如各種安全衛士），而 iOS 端的 IDFV( Identifier For Vendor)在不同廠商的 App 間是不同的,而且重新安裝IDFV會被重置。
| 裝置 | 規則 |
|---|---|
| Android | 1.10.5 之前版本，預設使用 UUID（例如：550e8400-e29b-41d4-a716-446655440000），App 解除安裝重灌 UUID 會變，為了保證裝置 ID 不變，可以通過配置使用 AndroidId（例如：774d56d682e549c3）；1.10.5 及之後的版本 SDK 預設使用 AndroidId 作為裝置 ID，如果 AndroidId 獲取不到則獲取隨機的 UUID。 |
| iOS | 1.10.18 及之後版本，如果 App 引入了 AdSupport 庫，SDK 預設使用 IDFA 作為匿名 ID。1.10.18 之前版本，可以優先使用 IDFV（例如：1E2DFA10-236A-47UD-6641-AB1FC4E6483F），如果 IDFV 獲取失敗，則使用隨機的 UUID（例如：550e8400-e29b-41d4-a716-446655440000），一般情況下都能夠獲取到 IDFV。如果使用 IDFV 或 UUID ，當使用者解除安裝重灌 App 時裝置 ID 會變。也可以通過配置使用 IDFA（例如：1E2DFA89-496A-47FD-9941-DF1FC4E6484A），如果開啟 IDFA ，可以優先獲取 IDFA，如果獲取失敗再嘗試獲取 IDFV。使用 IDFA 能避免使用者在重灌 App 後裝置 ID 發生變化的情況，需要注意的是IDFA 也是可以被重置的 |
登入 ID
登入 ID 通常是業務資料庫裡的主鍵或其它唯一標識。所以 登入 ID，相對來說更精確更持久。但是，使用者在使用時不一定註冊或者登入，而這個時候是沒有登入 ID 的。
平臺 ID
| 裝置 | 規則 |
|---|---|
| JavaScript | 預設情況下使用 cookie_id（例如：15ffdb0a3f898-02045d1cb7be78-31126a5d-250125-15ffdb0a3fa40a），cookie_id 存貯在瀏覽器的 cookie 中，依然有被重置的風險 這裡還有一個問題，就是 cookie 只能隸屬於同一個域名，也就是說你訪問郵箱的 cookie ，與百度廣的 cookie 並不是同一個，所以在網站與網站也要做 ID Mapping ，這就是為什麼你在百度上搜尋了“養生”，到購物網站上就會給你推薦“枸杞”。 |
| 微信小程式 | 預設情況下使用 UUID（例如：1558509239724-9278730-00c1875d5f63f8-41373096），但是刪除小程式，UUID 會變。為了保證裝置 ID 不變，建議獲取並使用 openid（例如：oWDMZ0WHqfsjIz7A9B2XNQOWmN3E）。 如果選擇使用 openid 的話，請注意【操作暫存】，由於獲取 openid 是一個非同步的操作，但是冷啟動事件等會先發生，這時候這個冷啟動事件的 distinct_id 就不對了。所以我們會把先發生的操作，暫存起來，等獲取到 openid 等後呼叫 sa.init() 後才會傳送資料。 openid 的獲取和操作暫存的方法。 |
其實這裡的平臺指的一些大的生態系統，例如微信的生態、今日頭條等，我們很多依賴這些平臺的應用就可以使用使用者在這些平臺上的使用者標識作為標識,當然我們也可以在此基礎上為我們自己平臺上的使用者建立屬於本平臺的使用者表示，往往就是使用者的登入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 的應用。
知識星球
通過調查，大部分同學表示願意加入知識星球，我也覺得這樣讓大家的提問更加有層次和意義，而不是問一些比較膚淺和不太合適的問題，有問題也能自己先查詢一下，這樣更好的交流和解答疑問，提升時間利用率。
加入星球可以獲得什麼：
- 博主總結的大資料學習資料免費獲得；
- 可以向星主和嘉賓提問；
- 互相交流，別人的提問和答案所有人都可以看到；
- 每週分享大資料前沿知識；
- 每週分享大資料面試題目和麵試技巧；
知識星球是付費的，如果你不想知識付費，也沒關係我這也有免費的微信群，加我微信：ddxygq，回覆: 加群，我拉你進大資料交流群。知識星球完全是自願付費加入。平時問答，資料分享等，知識星球成員優先，大家都是出來打工的，都不容易，不喜勿噴。
