早晨起牀的時候，發現自己尿分叉，我沒有多想，簡單洗洗就匆忙出門。路過早餐店，我看到師傅熟練的拉扯一小塊麪糰，拉至細長條，然後放入油鍋中，不一會功夫，一根屎黃色的油條便出鍋了，賣相不錯。我在想，小到炸屎黃色的油條，大到學習，其實都是一個熟能生巧的過程。
數據倉庫系列文章(持續更新)
- 數倉架構發展史
- 數倉建模方法論
- 數倉建模分層理論
- 數倉建模—寬表的設計
- 數倉建模—指標體系
- 數據倉庫之拉鍊表
- 數倉—數據集成
- 數倉—數據集市
- 數倉—商業智能系統
- 數倉—埋點設計與管理
- 數倉—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，回覆: 加羣，我拉你進大數據交流羣。知識星球完全是自願付費加入。平時問答，資料分享等，知識星球成員優先，大家都是出來打工的，都不容易，不喜勿噴。
