首先結論是令人失望的，對於android來說，這是一個沒有完美方案的問題。大家只能努力提高它的準確性，對於大的公司來說，可以自己開發出一套自己的機制，例如我上家公司成立過一個手機指紋的專案，專門處理裝置唯一性的問題防止使用者刷單，原理很簡單，就是儘可能的把手機能讀取到的資訊獲取到上傳到後臺，甚至令人髮指的連當前電量都上傳了，然後後臺動態調整演算法得出結論。如果目前對裝置唯一標誌敏感度不高，可以參考友盟的思路，實現一套自己簡易版的deviceId，正常情況下應該夠用了。友盟ID思路如下文：

簡單來說，

Android系統根據IMEI號+MAC地址標識裝置（獨立使用者）的唯一性；iOS系統根據OpenUDID標識裝置（使用者）的唯一性；WP系統根據ANID標識裝置（使用者）的唯一性，使用者聯網啟動應用之後才能統計到。

根據能否追蹤到單個獨立的裝置, 可以將一個統計系統分為可區分統計（Discriminative Statistics）和不可區分統計（Non-Discriminative Statistics）。友盟提供的是可區分統計，也就是會利用一個身份識別符號（Unique ID，以後簡稱 ID）長期追蹤單個裝置的資料。作為對比，早期的網站統計都是不可區分統計，例如頁面訪問次數，獨立 IP 數等；現代的網站統計都是基於 Cookie 或硬體指紋的可區分統計。由於智慧裝置提供了足夠多的硬體指紋和計算能力，友盟從第一天開始就專注於可區分統計。

大多數移動統計的 ID 都是通過系統 ID 生成的，包括但不限於 IMEI、MAC、Android ID。最著名的 ID 莫過於 UDID， 迫於隱私的壓力，蘋果最終廢棄了 UDID 和 MAC 地址。

大多數網站統計都是基於 Cookie的，因此是暫態ID（Temporal ID）。OpenUDID 就是一個典型的暫態ID。

蘋果的 IDFA 和 IDFV 都是系統ID，但是他們同時也是暫態ID。

由於可區分統計涉及到使用者隱私，因此友盟在計算中使用的都不是系統 ID ，而是自己的 UMID。友盟不會向第三方[1]提供包含原始 ID 或 UMID 的資料，而是提供聚合後的結果。UMID 既不是系統ID也不是暫態ID，它是一個在不斷演化的ID解決方案。本文將會解釋友盟為什麼要設計 UMID，又為何要不斷地改進這個方案。

進行可區分統計的基礎是確立一個可靠的身份識別符號，這看上去是一個很簡單的事情，只需要選擇一個ID，或者人為構造一個類Cookie ID，就可以完成獨立使用者量、留存等分析。但遺憾的是，除了蘋果已經廢除的UDID，幾乎沒有一個接近完美的ID。

為了方便討論，首先忽略假資料的存在，假設每個裝置都有一個真實的身份標識X。可區分統計的目標是選擇一個合適的身份標識I，使得基於I的統計結果儘可能地和 X 一致。

首先，我們引入兩個概念ID衝突（Collision）和ID漂移（Jitter）。

對於某個裝置集合（Device Cohort），在某個時間段內，總是可以測量 X 和 I 的數量，用 Count(X) 和 Count (I) 來表示。如果在足夠短的時間內

我們稱 I 是一個存在衝突的 ID。

對於某個裝置集合（Device Cohort），在某個時間段內，總是可以測量 X 和 I 的數量，用 Count(X) 和 Count (I) 來表示。如果在足夠長的時間內

則我們稱 I 是一個存在漂移的 ID。

Android 裝置的IMEI 就是一個存在嚴重衝突的 ID，根據我們的估算，其衝突率大於 3%。這是因為很多山寨機的IMEI 是相同的。

Android 裝置的 MAC 也是一個存在衝突的ID，因為很多山寨機的MAC也是相同的。此外，MAC還是一個典型的存在嚴重漂移的 ID，這是因為 Android 的原始碼中有一段隨機生成MAC  地址後24位的程式碼被濫用了（參考閱讀: MAC地址漂移的問題）。

接下來，我們可以定性分析一下ID衝突和漂移對統計資料的影響：

當一個ID僅存在衝突的時候，利用這個ID統計的DAU和安裝都會被低估，但是有可能會高估留存。但是這些影響都是溫和的，例如5% 的ID衝突僅僅會導致DAU至多被低估 5%，而對留存的影響幾乎可以忽略。

當一個ID僅存在漂移的時候，利用這個ID統計的DAU和安裝都會被高估，同時會影響留存。當漂移較大的時候，對統計指標的影響是劇烈的。例如，一個每日漂移為5%的ID，可能會造成DAU被高估2%，但是會每天造成5%的虛假安裝（這是因為漂移會影響所有使用者，包括不活躍使用者），同時這些虛假安裝的留存在短期內偏高，但是長期留存則偏低（短期內沒有漂移的時候就會偏高，時間長了，漂移了就會偏低）。任何類Cookie的ID都會有類似的性質，因此傳統的網站統計正在全面轉向更為可靠的裝置指紋。

當一個ID既存在衝突又存在漂移的時候，利用這個ID統計出來的DAU和安裝是完全不可靠的。以MAC地址為例，存在漂移的這部分裝置的MAC地址會頻繁變化，因此會製造大量的虛假安裝，同時留存率非常低。對於使用者量不大的應用而言，選擇存在這類ID的後果是災難性的。

綜上所述，當ID的漂移和衝突足夠小的時候，他們對可區分統計的影響都是可以忽略的。當這些誤差不可忽略的時候，ID的衝突造成的影響是溫和的，而ID的漂移則會嚴重干擾安裝和留存統計。

隨著蘋果廢棄UDID、MAC地址, 並且通過在iOS7上對剪貼簿限制導致OpenUDID無法在不同應用間共享，標誌著裝置ID的控制權回到了蘋果手中，也表明了蘋果對使用者隱私保護的決心。

在後iOS7時代，ID的選擇是再清楚不過的，業內通用的ID主要是IDFA（即廣告標示符，advertisingIdentifier）和IDFV（即vendor標示符，identifierForVendor）。IDFA適用於對外的廣告推廣、交叉推薦等跨應用的使用者追蹤；IDFV適用於使用者在應用內的行為追蹤。

當然，對於移動統計平臺而言，必須要保證統計的相容性和容錯性。這也是為什麼我們一直強調的是使用一個不斷優化的UMID解決方案，而不是任何一個具體的ID。

對於Android平臺，由於系統生態的開放性，ID的選擇也一直是一個頭疼的問題。

（1）單一ID

如前文所述，IMEI和MAC都不是最好的ID。特別是MAC地址，幾乎是一個不可用的ID。

（2）組合ID

有些開發者會選擇使用多個ID合併成一個組合ID，例如

利用前面的分析不難得出，組合ID將會極大地降低衝突，但是會放大漂移。對於組合ID而言，任何一個源ID的漂移都會造成它的漂移。

開發者應該儘量避免CID，一定要使用也需要避免使用MAC地址。如果已經在使用CID，那麼請確保在下一個版本把CID當作一個Cookie ID持久化，只有在Cookie丟失的情況下才重新生成CID。這樣的策略可以儘量保證ID的延續性，同時緩解漂移造成的影響。

由於UMID還在演化之中，這裡只能簡單地解釋UMID的生命週期。UMID是一個極度保守的ID，當一個裝置被分配了某個UMID以後，友盟會盡量保證這個UMID不會發生變化。因此，UMID的生成策略受到了友盟歷史資料的限制，最重要的設計目標是確保穩定性和資料一致性。友盟會持續地監控衝突和漂移，並且會盡量降低漂移，將衝突控制在合理的範圍內。正如世界上沒有永動機一樣，UMID並不是一個完美的ID。

為進一步的提高ID質量，友盟推出了全新的SDK。這個版本的SDK從設計到釋出用了差不多一年，內部代號是 Prime Radiant，來自阿西莫夫的科幻小說。通過Prime Radiant提供的新特性，友盟將能更好地監控ID訊號源的質量，並且能夠根據實際的資料來調整策略，充分利用裝置ID和暫態ID的優勢和劣勢。Prime Radiant 還充分利用了智慧裝置的計算能力，利用密碼學手段來提高資料質量和可靠性。

正是得益於Prime Radiant 測試階段的資料，友盟才能精確地對各類ID的質量進行定量分析。本文的很多結論都離不開這些資料。對於關心資料質量和資料安全的開發者，建議升級友盟新版SDK 進行體驗、測評。