唯一 ID 的最佳做法

本文件說明如何根據您的用途，為應用程式選取適當 ID。

如需查看有關 Android 權限的一般資訊，請參閱「權限總覽」一文。如要瞭解使用 Android 權限的具體最佳做法，請參閱「應用程式權限最佳做法」。

使用 Android ID 的最佳做法

為了保護使用者的隱私權，請使用符合應用程式用途且最嚴格的 ID。請特別遵循下列最佳做法：

  1. 盡可能選擇可由使用者重設的 ID。即使應用程式使用無法重設的硬體 ID 以外的 ID，也能執行大部分用途。

  2. 避免使用硬體 ID。在大多數情況下，您可以避免使用國際行動裝置識別碼 (IMEI) 等硬體 ID，而不會限制必要功能。

    Android 10 (API 級別 29) 針對無法重設的 ID (包括 IMEI 和序號) 新增限制。您的應用程式必須是裝置或設定檔擁有者應用程式，或是具備特殊電信業者權限，或是具備 READ_PRIVILEGED_PHONE_STATE 特權權限，才能存取這些 ID。

  3. 只將廣告 ID 用於剖析使用者或廣告用途。使用廣告 ID 時，請一律尊重使用者對廣告追蹤的選擇。如果您必須將廣告 ID 與個人識別資訊建立連結，請務必取得使用者的明確同意。

  4. 請勿跨平台重設廣告 ID。

  5. 請盡可能使用 Firebase 安裝 ID (FID) 或私密儲存的 GUID 來處理所有其他用途 (支付詐欺防範和電話服務除外)。對於絕大多數的非廣告用途，FID 或 GUID 應該就足夠了。

  6. 使用適合您用途的 API，盡可能降低隱私權風險。如要保護高價值內容，請使用 DRM API；如要防範濫用行為，請使用 Play Integrity API。如要判斷裝置是否正規，最簡單的方法就是使用 Play Integrity API。

本指南的其餘部分會進一步說明在開發 Android 應用程式的情況下，這些規則的運作方式。

使用廣告 ID

廣告 ID 是可由使用者重設的 ID，適合用於廣告用途。不過，使用這個 ID 時，請留意以下幾點：

一律尊重使用者重設廣告 ID 的意願。請勿在未經使用者同意的情況下，使用其他 ID 或指紋將後續廣告 ID 連結在一起，以便跨越使用者重設。《Google Play 開發人員內容政策》規定如下：

「...廣告 ID 經過重設後，在未經使用者明確同意下，新 ID 不得與舊 ID 本身或其衍生資料建立連結。」

一律尊重相關的個人化廣告標記。使用者可在廣告 ID 中設定廣告 ID，藉此限制與該 ID 相關聯的追蹤數量。請務必使用 AdvertisingIdClient.Info.isLimitAdTrackingEnabled() 方法，確保您不會違反使用者的意願。《Google Play 開發人員內容政策》規定如下：

「停用按照興趣顯示的廣告」或「停用廣告個人化」設定，您必須遵守使用者的「停用按照興趣顯示的廣告」設定。如果使用者啟用這項設定，您就不得使用廣告 ID 建立放送廣告所需的設定檔，或針對使用者放送個人化廣告。允許使用的功能包括內容相關廣告、展示頻率上限、轉換追蹤、報表與安全性，以及詐騙偵測。」

請注意，您使用的 SDK 可能會與廣告 ID 使用相關的隱私權或安全性政策。舉例來說，如果您將 true 傳入 Google Analytics SDK 的 enableAdvertisingIdCollection() 方法，請務必查看並遵守所有適用的 Analytics SDK 政策。

另外也請注意，《Google Play 開發人員內容政策》規定，廣告 ID「不得連結至個人識別資訊」或與任何永久裝置 ID 建立關聯，例如 SSAID、MAC 位址、IMEI 等。

舉例來說，假設您想收集資訊，以便填入下列資料欄的資料庫資料表：

TABLE-01
timestamp ad_id account_id clickid
資料表-02
account_id name dob country

在此範例中，ad_id 欄可透過兩個資料表中的 account_id 欄彙整至 PII，如果您未向使用者取得明確權限，則可能會違反《Google Play 開發人員內容政策》。

請注意，廣告主 ID 和 PII 之間的連結不一定這麼明確。在 PII 和廣告 ID 索引鍵表格中，可能會出現「準識別資訊」，這也會導致問題。舉例來說，假設我們將 TABLE-01 和 TABLE-02 變更為以下內容：

TABLE-01
timestamp ad_id clickid dev_model
TABLE-02
timestamp demo account_id dev_model name

在這種情況下，如果點擊事件相當罕見，您還是可以使用事件的時間戳記和裝置型號，將廣告客戶 ID TABLE-01 與 TABLE-02 中的 PII 進行彙整。

雖然很難保證資料集中沒有這類準識別資訊，但您可以盡可能將獨特資料概括化，避免最明顯的彙整風險。在上述範例中，這意味著降低時間戳記的準確率，讓每個時間戳記都會顯示同一個模型的多部裝置。

其他解決方案包括：

  • 未設計用來明確連結個人識別資訊與廣告 ID 的表格。在上述第一個範例中，這表示不包含 TABLE-01 中的 account_id 資料欄。

  • 針對可存取廣告 ID 鍵資料和 PII 的使用者或角色，區隔及監控存取控制清單 (ACL)。 透過嚴格控管和稽核同時存取兩個來源的功能 (例如在資料表之間執行彙整)，您就能降低廣告 ID 和 PII 之間的關聯風險。一般來說，控制存取權的意思是指執行下列操作：

    1. 請將廣告客戶 ID 鍵值資料和 PII 的存取控制清單 (ACL) 分開，盡量減少兩個 ACL 中的個人或角色數量。
    2. 實作存取記錄和稽核功能，以便偵測並管理這項規則的任何例外狀況。

如要進一步瞭解如何負責任地使用廣告 ID，請參閱 AdvertisingIdClient API 參考資料。

使用 FID 和 GUID

如要找出裝置上執行的應用程式執行個體，最直接的解決方案是使用 Firebase 安裝 ID (FID)。在多數非廣告用途中，這是建議採用的解決方案。只有已配置的應用程式例項可以存取此 ID，而且由於此 ID 只會在應用程式安裝時保留，因此 (相對來說) 很容易重設。

因此，與無法重設的裝置層級硬體 ID 相比，FID 可提供更佳的隱私權屬性。詳情請參閱 firebase.installations API 參考資料。

如果 FID 不實用，您也可以使用自訂全域專屬 ID (GUID)，來唯一識別應用程式執行個體。最簡單的方法是使用下列程式碼產生自己的 GUID：

Kotlin

var uniqueID = UUID.randomUUID().toString()

Java

String uniqueID = UUID.randomUUID().toString();

由於此 ID 在全球皆不重複，因此可用於識別特定應用程式例項。為避免在應用程式之間連結 ID 時發生問題，請將 GUID 儲存在內部儲存空間，而非外部 (共用) 儲存空間。詳情請參閱「資料和檔案儲存空間總覽」頁面。

不支援 MAC 位址

MAC 位址在全域範圍內都不會重複，且不會由使用者重設，而且在恢復原廠設定後仍然有效。基於這些原因，為了保護使用者隱私權，在 Android 6 以上版本中，只有系統應用程式可以存取 MAC 位址。第三方應用程式無法存取這些資料。

Android 11 中 MAC 位址可用性的變更

在指定 Android 11 以上版本的應用程式中，Passpoint 網路的 MAC 隨機產生功能會依照 Passpoint 設定檔，根據下列欄位產生唯一的 MAC 位址：

  • 完整網域名稱 (FQDN)
  • 運作範圍
  • 憑證，取決於 Passpoint 設定檔中使用的憑證：
    • 使用者憑證：使用者名稱
    • 憑證憑證：憑證和憑證類型
    • SIM 卡憑證：EAP 類型和 IMSI

此外，非特權應用程式無法存取裝置的 MAC 位址，只能查看具有 IP 位址的網路介面。這會影響 getifaddrs() 和 NetworkInterface.getHardwareAddress() 方法，以及傳送 RTM_GETLINK Netlink 訊息。

以下列出應用程式受到這項異動影響的方式：

  • NetworkInterface.getHardwareAddress() 會針對每個介面傳回 null。
  • 應用程式無法在 NETLINK_ROUTE 通訊端使用 bind() 函式。
  • ip 指令不會傳回介面的相關資訊。
  • 應用程式無法傳送 RTM_GETLINK 訊息。

請注意，多數開發人員應使用較高層級的 ConnectivityManager API，而非 NetworkInterface、getifaddrs() 或 Netlink 通訊端等較低層級的 API。舉例來說，如果應用程式需要目前路線的最新資訊，可以使用 ConnectivityManager.registerNetworkCallback() 監聽網路變更，並呼叫網路的相關 LinkProperties.getRoutes()，藉此取得這類資訊。

ID 特性

Android 作業系統提供多種具有不同行為特性的 ID。您應使用的 ID 取決於下列特性與用途的搭配方式。不過，這些特性也涉及隱私權問題，因此請務必瞭解這些特性如何相互影響。

範圍

識別碼範圍會說明哪些系統可以存取該識別碼。Android 識別符範圍通常分為三種版本：

  • 單一應用程式：ID 是應用程式內部的 ID，其他應用程式無法存取。
  • 應用程式群組：預先定義的相關應用程式群組可存取這個 ID。
  • 裝置：裝置上安裝的所有應用程式都能存取此 ID。

您授予 ID 的範圍越廣，該 ID 被用於追蹤的風險就越高。反之，如果一個 ID 只能由單一應用程式執行個體存取，就無法用於追蹤不同應用程式中交易的裝置。

可重設性和持久性

可重設性和持久性會定義 ID 的生命週期，並說明如何重設 ID。常見的重設觸發條件包括：應用程式內重設、透過系統設定重設、啟動時重設，以及安裝時重設。Android 識別碼的生命週期可能有所不同，但生命週期通常與 ID 的重設方式有關：

  • 僅限工作階段：每次使用者重新啟動應用程式時都會使用新的 ID。
  • 安裝重設：每次使用者解除安裝並重新安裝應用程式時，都會使用新的 ID。
  • 恢復原廠設定：使用者每次將裝置恢復原廠設定時，系統都會使用新的 ID。
  • FDR-persistent：ID 會在恢復原廠設定後保留。

重設功能可讓使用者建立與任何現有設定檔資訊無關的新 ID。識別碼持續存在的時間越長，可靠性越高，例如在恢復原廠設定後仍持續存在，使用者遭到長期追蹤的風險就越高。如果在應用程式重新安裝時重設 ID，這麼做可減少持續性，並提供 ID 重設的管道，即使沒有明確的使用者控制項，也能從應用程式或系統設定中重設 ID。

唯一性

唯一性可確立衝突的可能性，也就是在相關範圍內存在相同的 ID。從最高層級來看，全球唯一 ID 永遠不會發生衝突，即使在其他裝置或應用程式中也是如此。否則，唯一性程度取決於 ID 的熵值，以及用於建立 ID 的隨機來源。舉例來說，如果使用安裝日期的農曆日期 (例如 2019-03-01) 來播種隨機 ID，發生衝突的機率會比使用安裝日期的 Unix 時間戳記 (例如 1551414181) 來播種 ID 高出許多。

一般來說，使用者帳戶 ID 可視為不重複。也就是說，每個裝置/帳戶組合都有專屬 ID。另一方面，在某個群體中，識別碼越不具唯一性，隱私權保護程度就越高，因為這類識別碼不利於追蹤個別使用者。

完整性防護與不可實現性

您可以使用難以偽造或重播的 ID，證明相關聯的裝置或帳戶具有特定屬性。舉例來說，您可以證明這部裝置不是垃圾訊息散佈者使用的虛擬裝置。難以偽造的 ID 也提供不可否認性。如果裝置使用密鑰簽署訊息，就很難聲稱訊息是由他人的裝置傳送。不可否認性可能是使用者想要的事物 (例如驗證付款)，也可能是不理想的屬性，例如使用者所遺憾的訊息。

常見用途和適合的 ID

本節提供使用硬體 ID (例如 IMEI) 的替代方案。我們不建議使用硬體 ID，因為使用者無法重設硬體 ID，且硬體 ID 的範圍僅限於裝置。在許多情況下，應用程式層級的 ID 就足以應付。

帳戶

電信業者狀態

在這種情況下，您的應用程式會使用電信業者帳戶與裝置的電話和簡訊功能互動。

建議使用的 ID：IMEI、IMSI 和 Line1

為什麼會顯示這項推薦內容？

如果運營商相關功能需要使用硬體 ID，則可以使用硬體 ID。舉例來說，您可以使用這些 ID 在行動電信業者或 SIM 卡插槽之間切換，或是透過 IP (適用於 Line1) 傳送簡訊 - 以 SIM 卡為基礎的使用者帳戶。不過，對於沒有特權的應用程式，我們建議使用帳戶登入功能，在伺服器端擷取使用者裝置資訊。其中一個原因是，在 Android 6.0 (API 級別 23) 以上版本中，這些 ID 只能透過執行階段權限使用。使用者可能會停用這項權限，因此應用程式應妥善處理這些例外狀況。

行動裝置訂閱狀態

在這種情況下，您需要將應用程式功能與裝置上的特定行動服務訂閱項目建立關聯。舉例來說，您可能需要依據裝置的行動訂閱項目，透過 SIM 卡驗證特定付費應用程式功能的存取權。

建議使用的 ID： Subscription ID API，用於識別裝置上使用的 SIM 卡。

訂閱 ID 會提供索引值 (從 1 開始)，用於專屬識別裝置上使用的已安裝 SIM 卡 (包括實體和電子 SIM 卡)。透過這個 ID，應用程式可以將其功能與特定 SIM 卡的各種訂閱資訊建立關聯。除非裝置恢復原廠設定，否則針對特定 SIM 卡這個值保持不變。但是在某些情況下，相同的 SIM 卡在不同裝置上可能會有不同的訂閱 ID，或是不同裝置上的不同 SIM 卡 ID 都相同。

為什麼會顯示這項建議？

有些應用程式目前可能會為了這個目的而使用 ICC ID。由於 ICC ID 是全域唯一且無法重設，因此自 Android 10 起，存取權已限制為具有 READ_PRIVILEGED_PHONE_STATE 權限的應用程式。從 Android 11 開始，Android 會透過 getIccId() API 進一步限制 ICCID 存取權，不論應用程式的目標 API 級別為何。受影響的應用程式應改用 Subscription ID。

單一登入

在此情況下，應用程式提供單一登入體驗，可讓使用者將現有帳戶連結至貴機構。

建議使用的 ID：與帳戶管理員相容的帳戶，例如 Google 帳戶連結

為什麼會顯示這項推薦內容？

Google 帳戶連結功能可讓使用者將使用者現有的 Google 帳戶連結至您的應用程式，讓您以更安全的方式存取貴機構的產品和服務。此外，您也可以定義自訂 OAuth 範圍，只分享必要資料，明確定義資料的使用方式，提升使用者信任度。

廣告

指定目標

在這種情況下，應用程式會建立使用者興趣的個人資料，以便向他們顯示更切合需求的廣告。

建議使用的 ID：如果應用程式使用 ID 放送廣告，並將 ID 上傳或發布至 Google Play，該 ID 必須是廣告 ID。

為什麼會顯示這項建議？

這是與廣告相關的用途，可能需要在貴機構的不同應用程式中提供的 ID，因此使用廣告 ID 是最合適的解決方案。根據 Google Play 開發人員內容政策，廣告用途必須使用廣告 ID，因為使用者可以重設廣告 ID。

無論您是否會在應用程式中分享使用者資料，如果您是為了廣告目的收集及使用使用者資料，就必須在 Play 管理中心「應用程式內容」頁面的「資料安全性」專區中聲明廣告目的。

數據評估

在這種情況下，應用程式會根據使用者在同一裝置上使用貴機構應用程式的行為，建立使用者設定檔。

建議使用的 ID：廣告 ID 或 Play Install referrer API

為什麼會顯示這項推薦內容？

這是與廣告相關的用途，可能需要在貴機構的不同應用程式中提供的 ID，因此使用廣告 ID 是最合適的解決方案。如果您將 ID 用於廣告用途，則該 ID 必須是廣告 ID，因為使用者可以重設該 ID。如需瞭解詳情，請參閱 Google Play 開發人員內容政策。

轉換次數

在這個案例中，您將追蹤轉換，以偵測行銷策略是否成功。

建議使用的 ID：廣告 ID 或 Play 安裝參照來源 API

為什麼會顯示這項推薦內容？

這是與廣告相關的用途，可能需要在貴機構的不同應用程式中提供的 ID，因此使用廣告 ID 是最合適的解決方案。根據 Google Play 開發人員內容政策，使用者可能會重設廣告 ID，因此廣告用途必須使用廣告 ID。

再行銷

在這種情況下，應用程式會根據使用者先前的興趣顯示廣告。

建議使用的 ID：廣告 ID

為什麼會顯示這項推薦內容？

這是與廣告相關的用途，可能需要在貴機構的不同應用程式中提供的 ID，因此使用廣告 ID 是最合適的解決方案。根據 Google Play 開發人員內容政策，使用者可能會重設廣告 ID，因此廣告用途必須使用廣告 ID。

應用程式分析

在這種情況下，應用程式會評估使用者的行為，協助您判斷下列事項：

  • 貴機構的其他產品或應用程式可能適合使用者。
  • 如何讓使用者持續使用您的應用程式。
  • 評估已登出或匿名使用者的使用統計資料和分析資料。

可能的解決方案包括：

  • 應用程式組 ID：只要您不將使用者資料用於廣告用途，即可透過應用程式組 ID 分析機構擁有的多個應用程式中的使用者行為。如果您指定的是採用 Google Play 服務的裝置，建議您使用應用程式集 ID。
  • Firebase ID (FID)：FID 的範圍僅限於建立該 ID 的應用程式，因此無法用於追蹤跨應用程式的使用者。這個方法也很容易重設，因為使用者可以清除應用程式資料或重新安裝應用程式。FID 的建立程序非常簡單，請參閱 Firebase 安裝指南。

應用程式開發

當機回報

在此情況下，應用程式會收集使用者裝置當機的時間和原因相關資料。

建議使用的 ID：FID 或應用程式組 ID

為什麼會顯示這項推薦內容？

FID 的範圍限定在建立此 ID 的應用程式，可防止系統將 ID 用於跨應用程式追蹤使用者。此外，使用者可以清除應用程式資料或重新安裝應用程式，因此就能輕鬆重設。FID 的建立程序相當簡單，詳情請參閱 Firebase 安裝指南。只要您不將使用者資料用於廣告用途，即可透過應用程式集 ID 分析機構擁有的多個應用程式中使用者的行為。

成效報表

在這種情況下，應用程式會收集效能指標 (例如載入時間和電池用量)，以利改善應用程式品質。

建議使用的 ID： Firebase Performance Monitoring

為什麼會顯示這項推薦內容？

Firebase Performance Monitoring 可協助您專注於最重視的指標，並測試應用程式近期變更所造成的影響。

應用程式測試

在這種情況下，應用程式會評估使用者使用應用程式的體驗，以利測試或偵錯。

建議使用的 ID：FID 或應用程式組 ID

為什麼會顯示這項推薦內容？

FID 的範圍僅限於建立該 ID 的應用程式，因此無法用於追蹤不同應用程式的使用者。由於使用者可以清除應用程式資料或重新安裝應用程式，因此這類 ID 也能輕鬆重設。建立 FID 的程序很簡單，請參閱 Firebase 安裝指南。只要您不會將使用者資料用於廣告用途，即可透過應用程式集 ID 分析機構擁有的多個應用程式中使用者的行為。

跨裝置安裝

在這種情況下，如果應用程式已安裝在同一使用者的多部裝置上，應用程式就需要識別正確的應用程式執行個體。

建議使用的 ID：FID 或 GUID

為什麼會顯示這項推薦內容？

FID 是專為這項用途而設計，其範圍僅限於應用程式，因此無法用於追蹤不同應用程式的使用者，且會在應用程式重新安裝時重設。在極少數情況下，當 FID 不足時，您也可以使用 GUID。

安全性

濫用行為偵測

在這種情況下，您正在嘗試偵測多部假裝置來攻擊後端服務。

建議使用的 ID：Google Play Integrity API 完整性權杖

為什麼會顯示這項推薦內容？

如要驗證要求是否來自正版 Android 裝置，而非模擬器或其他假冒其他裝置的程式碼，請使用 Google Play Integrity API。

廣告詐欺

在這種情況下，應用程式會檢查使用者在應用程式中的曝光和動作是否真實且可驗證。

建議使用的 ID：廣告 ID

為什麼會顯示這項推薦內容？

根據 Google Play 開發人員內容政策，廣告用途必須使用廣告 ID，因為使用者可以重設廣告 ID。

數位版權管理 (DRM)

在此情況下，您的應用程式希望保護智慧財產或付費內容的詐欺性存取。

建議使用的 ID：使用 FID 或 GUID 會迫使使用者重新安裝應用程式，以便規避內容限制，這會讓大多數使用者卻步。如果這項保護措施不足，Android 也提供 DRM API，可用於限制內容存取權，包括每個 APK 的 ID (Widevine ID)。

使用者偏好設定

在此情況下，應用程式會將每部裝置的使用者狀態儲存在應用程式，尤其是未登入的使用者。您可以將此狀態轉移至在同一部裝置上使用相同金鑰簽署的其他應用程式。

建議使用的 ID：FID 或 GUID

為什麼會顯示這項建議？

我們不建議透過重新安裝來保留資訊，因為使用者可能會想透過重新安裝應用程式來重設偏好設定。