鄭棟, 網易互聯(lián)網分析產品、可視化 BI 產品負責人。多年從事大數據技術相關工作，目前在網易管理互聯(lián)網分析、敏捷BI兩個數據分析產品線，在大數據技術、互聯(lián)網業(yè)務數據體系建設、團隊管理方面有豐富的經驗。 負責過網易旗下多個業(yè)務及產品的數據體系建設工作，也有應用分析、營銷監(jiān)測、用戶行為分析、可視化分析等多個數據產品的實戰(zhàn)落地經驗。
這是個歸因的問題，一般提到帳號打通，就會有歸因的討論 。
現在的分析產品在一般情況下，移動端會通過 SDK 生成唯一 ID 來標識用戶/設備。移動化發(fā)展早期，很多采集工具用過 mac address、IDFA、android_id、IMEI 等從移動操作系統(tǒng)可以獲取的設備軟硬件信息來標識設備，但隨著操作系統(tǒng)的發(fā)展，很多信息獲取接口要么被封禁，要么已經失去了精準性。反倒是一開始就通過自己生成的 ID 來標識用戶的工具，受到的影響不大，基本保持了用戶/設備標識的穩(wěn)定。
但這種方式有個問題，在用戶卸載、重裝或者刷機后，ID 信息會丟失，導致生成新的用戶/設備 ID。
我們采用過 ID Mapping 的技術來做過 ID 的打通：對每個用戶生成一個虛擬 ID，對同一個用戶的多個設備和帳號進行映射，并綁定起來。
可以通過操作系統(tǒng)提供的一些穩(wěn)定性稍差，但短時間還比較穩(wěn)定的指標，如 iOS 的 IDFA，來做 mapping。
借助分析產品的應用覆蓋率，如用戶是應用 A 和 B 的用戶，卸載并重新安裝 B 應用后，可以通過應用 A 的 ID 修復應用 B 的。
通過引入產品用戶帳號體系，來做綁定，這種方式穩(wěn)定性最強，但非登錄匿名用戶的問題不好解決。
通過 IP、Wi-Fi 信息、機器型號、甚至地理位置進行 mapping，這種方式需要用戶授權更多數據獲取權限，雖然是近似匹配，但當信息足夠多且發(fā)散（信息熵足夠大）時，也可以起到統(tǒng)一標識的作用。
通過這個虛擬 ID 實質上就打通了產品的多端數據。ID Mapping 體系的建設工作量不小，Mapping 后用戶標識如果需要發(fā)生調整，在基于事件的分析產品上需要對老數據進行重寫，比較復雜。所以對于一些強帳號體系的產品，可以退化到只用用戶帳號來做關聯(lián)，只有非登錄匿名用戶才用設備 ID 來標識，這往往是性價比比較高的方案。
推廣渠道歸因就方便了。
支持營銷效果評估的分析平臺會要求產品在平臺上生成推廣鏈接進行投放。用戶在點擊鏈接時，會從分析平臺的域下做跳轉再到目標頁，這樣就可以借助瀏覽器的 cookie 機制進行匹配，來對用戶來源進行歸因，但這種方式在移動端上面的表現不太好（iOS 已經取消了 SFSafariViewController 多應用共享 cookie 的支持）。除此之外，也可以采用 ID Mapping 提到的近似匹配技術，很多廠商聲稱的設備指紋技術大多也是這種，不太準，但定性分析是可以的。
歸因這塊，一些推廣渠道做了些工作，解決移動端不好溯源的問題：支持設備 ID 的回傳功能來方便產品歸因問題的解決。
產品方在投放鏈接的時候，遵照特定格式即可
比如
https://xxx.com/aaaafD?idfa=__IDFA__&imei=__IMEI__
渠道在用戶點擊廣告鏈接后，會把設備 ID 如 IDFA 或 IMEI 加到鏈接的內容里面，用戶激活后便可以通過相應 ID 匹配來歸因。
原文首發(fā)于微信號——Dtalks
作者：鄭棟——網易互聯(lián)網分析產品、可視化 BI 產品負責人
文章可以轉載, 但必須告知，并且以超鏈接形式標明文章原始出處和作者信息
干貨專訪和文章
【DTalk分享】黃一能：互聯(lián)網產品運營決策中用戶畫像的核心作用直播回顧
【DTalk分享】陳抒：產品設計中的用戶畫像直播回顧
【DTalk分享】吆喝科技王曄：A/B測試最佳實踐直播回顧
【DTalk精華】網易鄭棟：前端數據采集與分析那些事第一彈: 從數據埋點到AB測試
【DTalk精華】滴滴出行譙洪敏：前端數據采集與分析那些事第二彈：企業(yè)如何選擇自動埋點和可視化埋點
【DTalk精華】滴滴出行譙洪敏：前端數據采集與分析那些事第三彈：埋點需求整理原則于埋點流程規(guī)范
【DTalk專訪】滴滴譙洪敏：百家爭鳴的前端技術時代
【DTalk思考】顧青：互聯(lián)網團隊的數據驅動能力從哪里來？
