Các phương pháp hay nhất cho mã nhận dạng có thể xác định danh tính chính xác

Tài liệu này cung cấp hướng dẫn về cách chọn giá trị nhận dạng phù hợp cho ứng dụng dựa trên trường hợp sử dụng của bạn.

Để biết thông tin tổng quan về quyền trong Android, hãy xem bài viết Tổng quan về quyền. Để biết các phương pháp hay nhất cụ thể khi làm việc với quyền trong Android, hãy xem bài viết Các phương pháp hay nhất về quyền cho ứng dụng.

Các phương pháp hay nhất để thao tác với giá trị nhận dạng trên Android

Để bảo vệ quyền riêng tư của người dùng, hãy dùng giá trị nhận dạng hạn chế nhất đáp ứng trường hợp sử dụng của ứng dụng. Cụ thể, hãy làm theo các phương pháp hay nhất sau đây:

  1. Chọn giá trị nhận dạng mà người dùng có thể đặt lại bất cứ khi nào có thể. Ứng dụng của bạn có thể đạt được hầu hết các trường hợp sử dụng ngay cả khi ứng dụng đó sử dụng các giá trị nhận dạng khác ngoài mã nhận dạng phần cứng không đặt lại được.

  2. Tránh sử dụng giá trị nhận dạng phần cứng. Trong hầu hết các trường hợp sử dụng, bạn có thể tránh sử dụng giá trị nhận dạng phần cứng (chẳng hạn như Mã số nhận dạng thiết bị di động quốc tế (IMEI)) mà không bị giới hạn chức năng bắt buộc.

    Android 10 (API cấp 29) bổ sung các hạn chế đối với giá trị nhận dạng không thể đặt lại, bao gồm cả IMEI và số sê-ri. Ứng dụng của bạn phải là ứng dụng chủ sở hữu thiết bị hoặc hồ sơ, có các quyền đặc biệt của nhà mạng hoặc có quyền READ_PRIVILEGED_PHONE_STATE đặc quyền để truy cập vào các giá trị nhận dạng này.

  3. Chỉ sử dụng mã nhận dạng cho quảng cáo trong các trường hợp sử dụng là quảng cáo hoặc lập hồ sơ người dùng. Khi sử dụng Mã nhận dạng cho quảng cáo, hãy luôn tôn trọng lựa chọn của người dùng về hoạt động theo dõi quảng cáo. Nếu bạn phải kết nối giá trị nhận dạng cho quảng cáo với thông tin nhận dạng cá nhân, hãy chỉ làm như vậy khi có sự đồng ý rõ ràng của người dùng.

  4. Không được kết nối các lần đặt lại Mã nhận dạng cho quảng cáo.

  5. Sử dụng mã nhận dạng lượt cài đặt Firebase (FID) hoặc GUID được lưu trữ riêng tư bất cứ khi nào có thể cho tất cả các trường hợp sử dụng khác, ngoại trừ trường hợp phòng chống gian lận thanh toán và điện thoại. Đối với phần lớn các trường hợp sử dụng không liên quan đến quảng cáo, bạn chỉ cần FID hoặc GUID là đủ.

  6. Sử dụng các API phù hợp với trường hợp sử dụng của bạn để giảm thiểu nguy cơ xâm phạm quyền riêng tư. Sử dụng DRM API để bảo vệ nội dung có giá trị cao và API Tính toàn vẹn của Play để chống hành vi sai trái. API Tính toàn vẹn của Play là cách dễ nhất để xác định xem một thiết bị có phải là thiết bị thực hay không mà không gây ra rủi ro về quyền riêng tư.

Các phần còn lại của hướng dẫn này sẽ trình bày chi tiết về những quy tắc này trong bối cảnh phát triển ứng dụng Android.

Làm việc với mã nhận dạng cho quảng cáo

Mã nhận dạng cho quảng cáo là một giá trị nhận dạng mà người dùng có thể đặt lại và phù hợp với các trường hợp sử dụng quảng cáo. Tuy nhiên, bạn cần lưu ý một số điểm chính khi sử dụng mã nhận dạng này:

Luôn tôn trọng ý định của người dùng khi đặt lại mã nhận dạng cho quảng cáo. Không được bắc cầu cho các lần đặt lại của người dùng bằng cách sử dụng một giá trị nhận dạng hoặc dấu vân tay khác để liên kết các mã nhận dạng cho quảng cáo tiếp theo với nhau khi chưa có sự đồng ý của người dùng. Chính sách của Google Play dành cho nhà phát triển về nội dung quy định những điều sau:

"...nếu đặt lại, bạn không được kết nối mã nhận dạng mới cho quảng cáo với một mã nhận dạng cho quảng cáo trước đây hoặc với dữ liệu thu được qua một mã nhận dạng cho quảng cáo trước đây khi chưa có sự đồng ý rõ ràng của người dùng."

Luôn tôn trọng cờ Quảng cáo được cá nhân hoá có liên kết. Mã nhận dạng cho quảng cáo có thể định cấu hình, tức là người dùng có thể giới hạn mức độ theo dõi liên kết với mã nhận dạng này. Luôn sử dụng phương thức AdvertisingIdClient.Info.isLimitAdTrackingEnabled() để đảm bảo rằng bạn không đi ngược lại mong muốn của người dùng. Chính sách nội dung dành cho nhà phát triển của Google Play quy định những điều sau:

"...bạn phải tuân thủ chế độ cài đặt "Chọn không nhận quảng cáo dựa trên mối quan tâm" hay "Chọn không sử dụng tính năng cá nhân hoá quảng cáo" của người dùng. Nếu người dùng đã bật chế độ cài đặt này, bạn không thể dùng mã nhận dạng cho quảng cáo để tạo hồ sơ người dùng cho mục đích quảng cáo hoặc để phân phát quảng cáo được cá nhân hoá cho người dùng. Một số hoạt động được phép: quảng cáo theo bối cảnh, giới hạn tần suất, theo dõi lượt chuyển đổi, báo cáo, bảo mật và phát hiện gian lận."

Lưu ý mọi chính sách về quyền riêng tư hoặc bảo mật liên quan đến các SDK mà bạn sử dụng có liên quan đến việc sử dụng mã nhận dạng cho quảng cáo. Ví dụ: nếu bạn truyền true vào phương thức enableAdvertisingIdCollection() từ SDK Google Analytics, hãy nhớ xem xét và tuân thủ tất cả các chính sách SDK Analytics hiện hành.

Ngoài ra, xin lưu ý rằng Chính sách nội dung dành cho nhà phát triển của Google Play yêu cầu rằng Mã nhận dạng cho quảng cáo "không được liên kết với thông tin nhận dạng cá nhân hoặc liên kết với bất kỳ giá trị nhận dạng cố định nào của thiết bị (ví dụ: SSAID, địa chỉ MAC, IMEI, v.v.)."

Ví dụ: giả sử bạn muốn thu thập thông tin để điền vào các bảng cơ sở dữ liệu có các cột sau:

TABLE-01
timestamp ad_id account_id clickid
TABLE-02
account_id name dob country

Trong ví dụ này, cột ad_id có thể được kết hợp với thông tin nhận dạng cá nhân thông qua cột account_id trong cả hai bảng. Điều này sẽ vi phạm Chính sách nội dung dành cho nhà phát triển của Google Play nếu bạn không nhận được sự cho phép rõ ràng của người dùng.

Xin lưu ý rằng không phải lúc nào mối liên kết giữa Mã nhận dạng nhà quảng cáo và PII cũng rõ ràng như vậy. Có thể có "giá trị nhận dạng gần đúng" xuất hiện trong cả bảng có khoá PII và mã nhận dạng quảng cáo, điều này cũng gây ra vấn đề. Ví dụ: giả sử chúng ta thay đổi TABLE-01 và TABLE-02 như sau:

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

Trong trường hợp này, với các sự kiện nhấp chuột đủ hiếm, vẫn có thể kết hợp giữa BẢNG-01 mã nhận dạng nhà quảng cáo và thông tin nhận dạng cá nhân có trong BẢNG-02 bằng cách sử dụng dấu thời gian của sự kiện và kiểu thiết bị.

Mặc dù thường rất khó để đảm bảo rằng không có giá trị nhận dạng giả nào như vậy trong một tập dữ liệu, nhưng bạn có thể ngăn chặn những rủi ro kết hợp rõ ràng nhất bằng cách khái quát hoá dữ liệu duy nhất nếu có thể. Trong ví dụ trước, điều này có nghĩa là giảm độ chính xác của dấu thời gian để nhiều thiết bị có cùng một kiểu máy xuất hiện cho mỗi dấu thời gian.

Sau đây là các giải pháp khác:

  • Không thiết kế các bảng liên kết rõ ràng thông tin nhận dạng cá nhân với Mã nhận dạng cho quảng cáo. Trong ví dụ đầu tiên ở trên, điều này có nghĩa là không đưa cột account_id vào TABLE-01.

  • Phân tách và giám sát danh sách kiểm soát quyền truy cập cho những người dùng hoặc vai trò có quyền truy cập vào cả dữ liệu có khoá Mã nhận dạng cho quảng cáo và PII. Bằng cách kiểm soát chặt chẽ và kiểm tra khả năng truy cập đồng thời vào cả hai nguồn (ví dụ: bằng cách thực hiện thao tác kết hợp giữa các bảng), bạn sẽ giảm nguy cơ liên kết giữa Mã nhận dạng cho quảng cáo và thông tin nhận dạng cá nhân. Nói chung, việc kiểm soát quyền truy cập có nghĩa là bạn phải làm những việc sau:

    1. Giữ danh sách kiểm soát truy cập (ACL) cho dữ liệu có khoá nhận dạng nhà quảng cáo và PII rời rạc để giảm thiểu số lượng cá nhân hoặc vai trò có trong cả hai ACL.
    2. Triển khai tính năng ghi nhật ký và kiểm tra quyền truy cập để phát hiện và quản lý mọi trường hợp ngoại lệ đối với quy tắc này.

Để biết thêm thông tin về cách sử dụng Mã nhận dạng cho quảng cáo một cách có trách nhiệm, hãy xem tài liệu tham khảo về API AdvertisingIdClient.

Làm việc với FID và GUID

Giải pháp đơn giản nhất để xác định một phiên bản ứng dụng đang chạy trên thiết bị là sử dụng mã nhận dạng lượt cài đặt Firebase (FID). Đây là giải pháp được đề xuất trong phần lớn các trường hợp sử dụng không phải là quảng cáo. Chỉ phiên bản ứng dụng mà bạn đã cung cấp mới có thể truy cập vào giá trị nhận dạng này và bạn có thể (tương đối) dễ dàng đặt lại giá trị nhận dạng này vì giá trị nhận dạng này chỉ duy trì miễn là ứng dụng được cài đặt.

Do đó, FID cung cấp các thuộc tính quyền riêng tư tốt hơn so với mã nhận dạng phần cứng không đặt lại được và có phạm vi là thiết bị. Để biết thêm thông tin, hãy xem tài liệu tham khảo về API firebase.installations.

Trong trường hợp không thể dùng FID, bạn cũng có thể dùng mã nhận dạng duy nhất trên toàn cầu (GUID) tuỳ chỉnh để xác định riêng một phiên bản ứng dụng. Cách đơn giản nhất để làm việc này là tạo GUID của riêng bạn bằng mã sau:

Kotlin

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

Java

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

Vì giá trị nhận dạng này là duy nhất trên toàn cầu, nên bạn có thể dùng giá trị này để xác định một phiên bản ứng dụng cụ thể. Để tránh các vấn đề liên quan đến việc liên kết giá trị nhận dạng trên các ứng dụng, hãy lưu trữ GUID trong bộ nhớ trong thay vì bộ nhớ ngoài (dùng chung). Để biết thêm thông tin, hãy xem trang Tổng quan về bộ nhớ dữ liệu và tệp.

Không hoạt động với địa chỉ MAC

Địa chỉ MAC là duy nhất trên toàn cầu, người dùng không thể đặt lại và vẫn tồn tại sau khi đặt lại về trạng thái ban đầu. Vì những lý do này, để bảo vệ quyền riêng tư của người dùng, trên Android phiên bản 6 trở lên, quyền truy cập vào địa chỉ MAC chỉ được cấp cho các ứng dụng hệ thống. Các ứng dụng bên thứ ba không thể truy cập vào những dữ liệu này.

Các thay đổi về tính sẵn có của địa chỉ MAC trong Android 11

Trên các ứng dụng nhắm đến Android 11 trở lên, tính năng ngẫu nhiên hoá địa chỉ MAC cho các mạng Passpoint là theo từng hồ sơ Passpoint, tạo ra một địa chỉ MAC riêng biệt dựa trên các trường sau:

  • Tên miền đủ điều kiện (FQDN)
  • Realm
  • Thông tin xác thực, dựa trên thông tin xác thực được dùng trong hồ sơ Passpoint:
    • Thông tin đăng nhập của người dùng: tên người dùng
    • Thông tin xác thực chứng chỉ: chứng chỉ và loại chứng chỉ
    • Thông tin đăng nhập SIM: Loại EAP và IMSI

Ngoài ra, các ứng dụng không có đặc quyền không thể truy cập vào địa chỉ MAC của thiết bị; chỉ những giao diện mạng có địa chỉ IP mới hiển thị. Điều này ảnh hưởng đến các phương thức getifaddrs() và NetworkInterface.getHardwareAddress(), cũng như việc gửi thông báo RTM_GETLINK Netlink.

Sau đây là danh sách những cách mà các ứng dụng chịu ảnh hưởng của thay đổi này:

  • NetworkInterface.getHardwareAddress() trả về giá trị rỗng cho mọi giao diện.
  • Các ứng dụng không thể sử dụng hàm bind() trên các ổ cắm NETLINK_ROUTE.
  • Lệnh ip không trả về thông tin về các giao diện.
  • Ứng dụng không thể gửi tin nhắn RTM_GETLINK.

Xin lưu ý rằng hầu hết nhà phát triển nên sử dụng các API cấp cao của ConnectivityManager thay vì các API cấp thấp như NetworkInterface, getifaddrs() hoặc Netlink socket. Ví dụ: một ứng dụng cần thông tin mới nhất về các tuyến đường hiện tại có thể nhận được thông tin này bằng cách theo dõi các thay đổi về mạng bằng cách sử dụng ConnectivityManager.registerNetworkCallback() và gọi LinkProperties.getRoutes() được liên kết của mạng.

Đặc điểm của giá trị nhận dạng

Hệ điều hành Android cung cấp một số mã nhận dạng có đặc điểm hành vi khác nhau. Bạn nên sử dụng mã nhận dạng nào tuỳ thuộc vào cách các đặc điểm sau đây hoạt động với trường hợp sử dụng của bạn. Tuy nhiên, những đặc điểm này cũng có ý nghĩa đối với quyền riêng tư. Vì vậy, điều quan trọng là bạn phải hiểu cách những đặc điểm này tương tác với nhau.

Phạm vi

Phạm vi của giá trị nhận dạng giải thích những hệ thống có thể truy cập vào giá trị nhận dạng. Phạm vi của giá trị nhận dạng Android thường có 3 loại:

  • Một ứng dụng: Mã nhận dạng này nằm trong ứng dụng và các ứng dụng khác không truy cập được.
  • Nhóm ứng dụng: Mã nhận dạng này có thể truy cập được đối với một nhóm ứng dụng có liên quan được xác định trước.
  • Thiết bị: Tất cả ứng dụng đã cài đặt trên thiết bị đều có thể truy cập vào mã nhận dạng này.

Phạm vi được cấp cho một giá trị nhận dạng càng rộng thì nguy cơ giá trị nhận dạng đó bị dùng cho mục đích theo dõi càng lớn. Ngược lại, nếu chỉ một phiên bản ứng dụng có thể truy cập vào một giá trị nhận dạng, thì giá trị nhận dạng đó không thể dùng để theo dõi một thiết bị trên các giao dịch trong nhiều ứng dụng.

Khả năng đặt lại và tính liên tục

Khả năng đặt lại và tính liên tục xác định tuổi thọ của mã nhận dạng và giải thích cách đặt lại mã nhận dạng. Các điều kiện kích hoạt phổ biến để đặt lại bao gồm: đặt lại trong ứng dụng, đặt lại thông qua phần Cài đặt hệ thống, đặt lại khi khởi chạy và đặt lại khi cài đặt. Các giá trị nhận dạng Android có thể có thời gian tồn tại khác nhau, nhưng thời gian tồn tại thường liên quan đến cách đặt lại giá trị nhận dạng:

  • Chỉ phiên: Một mã nhận dạng mới được sử dụng mỗi khi người dùng khởi động lại ứng dụng.
  • Install-reset: Một mã nhận dạng mới được dùng mỗi khi người dùng gỡ cài đặt và cài đặt lại ứng dụng.
  • Đặt lại về trạng thái ban đầu (FDR): Một mã nhận dạng mới sẽ được dùng mỗi khi người dùng đặt lại thiết bị về trạng thái ban đầu.
  • FDR-persistent: Mã nhận dạng vẫn tồn tại sau khi đặt lại về trạng thái ban đầu.

Khả năng đặt lại cho phép người dùng tạo một mã nhận dạng mới không liên kết với bất kỳ thông tin hồ sơ hiện có nào. Một giá trị nhận dạng tồn tại càng lâu và càng đáng tin cậy (chẳng hạn như giá trị nhận dạng tồn tại sau khi đặt lại về trạng thái ban đầu), thì người dùng càng có nguy cơ bị theo dõi trong thời gian dài. Nếu mã nhận dạng được đặt lại khi cài đặt lại ứng dụng, thì điều này sẽ làm giảm khả năng duy trì và cung cấp phương tiện để đặt lại mã nhận dạng, ngay cả khi không có chế độ kiểm soát rõ ràng của người dùng để đặt lại mã nhận dạng trong ứng dụng hoặc phần Cài đặt hệ thống.

Điểm đặc biệt

Tính duy nhất xác định khả năng xảy ra xung đột; tức là có các giá trị nhận dạng giống hệt nhau trong phạm vi được liên kết. Ở cấp cao nhất, một giá trị nhận dạng duy nhất trên toàn cầu không bao giờ có xung đột, ngay cả trên các thiết bị hoặc ứng dụng khác. Nếu không, mức độ duy nhất sẽ phụ thuộc vào entropy của giá trị nhận dạng và nguồn ngẫu nhiên dùng để tạo giá trị nhận dạng đó. Ví dụ: khả năng xảy ra xung đột sẽ cao hơn nhiều đối với các giá trị nhận dạng ngẫu nhiên được gieo hạt bằng ngày trên lịch của lượt cài đặt (chẳng hạn như 2019-03-01) so với các giá trị nhận dạng được gieo hạt bằng dấu thời gian Unix của lượt cài đặt (chẳng hạn như 1551414181).

Nhìn chung, bạn có thể coi giá trị nhận dạng tài khoản người dùng là duy nhất. Tức là mỗi tổ hợp thiết bị/tài khoản đều có một mã nhận dạng duy nhất. Mặt khác, giá trị nhận dạng càng ít riêng biệt trong một nhóm dân số, thì khả năng bảo vệ quyền riêng tư càng cao vì giá trị nhận dạng đó ít hữu ích hơn cho việc theo dõi một người dùng riêng lẻ.

Bảo vệ tính toàn vẹn và tính không thể chối bỏ

Bạn có thể sử dụng một giá trị nhận dạng khó giả mạo hoặc phát lại để chứng minh rằng thiết bị hoặc tài khoản được liên kết có một số thuộc tính nhất định. Ví dụ: bạn có thể chứng minh rằng thiết bị không phải là thiết bị ảo do kẻ gửi thư rác sử dụng. Các giá trị nhận dạng khó giả mạo cũng mang lại tính không thể chối bỏ. Nếu thiết bị ký một thông báo bằng khoá bí mật, thì rất khó để khẳng định rằng thiết bị của người khác đã gửi thông báo đó. Tính không thể chối bỏ có thể là điều mà người dùng muốn, chẳng hạn như khi xác thực một khoản thanh toán, hoặc đó có thể là một thuộc tính không mong muốn, chẳng hạn như khi họ gửi một tin nhắn mà họ hối hận.

Các trường hợp sử dụng phổ biến và giá trị nhận dạng phù hợp để sử dụng

Phần này cung cấp các lựa chọn thay thế cho việc sử dụng mã nhận dạng phần cứng, chẳng hạn như IMEI. Bạn không nên sử dụng mã nhận dạng phần cứng vì người dùng không thể đặt lại mã nhận dạng này và mã nhận dạng này chỉ áp dụng cho thiết bị. Trong nhiều trường hợp, giá trị nhận dạng theo phạm vi ứng dụng là đủ.

Tài khoản

Trạng thái của hãng vận chuyển

Trong trường hợp này, ứng dụng của bạn tương tác với chức năng gọi điện và nhắn tin của thiết bị bằng tài khoản của nhà mạng.

Giá trị nhận dạng nên sử dụng: IMEI, IMSI và Line1

Tại sao có đề xuất này?

Bạn có thể sử dụng giá trị nhận dạng phần cứng nếu cần cho chức năng liên quan đến nhà mạng. Ví dụ: bạn có thể sử dụng các giá trị nhận dạng này để chuyển đổi giữa các nhà mạng di động hoặc khe cắm SIM, hoặc để gửi tin nhắn SMS qua IP (cho Line1) – tài khoản người dùng dựa trên SIM. Tuy nhiên, đối với các ứng dụng không có đặc quyền, bạn nên sử dụng tính năng đăng nhập bằng tài khoản để truy xuất thông tin thiết bị của người dùng ở phía máy chủ. Một lý do là trong Android 6.0 (API cấp 23) trở lên, bạn chỉ có thể sử dụng các giá trị nhận dạng này thông qua một quyền trong thời gian chạy. Người dùng có thể tắt quyền này, vì vậy, ứng dụng của bạn phải xử lý những trường hợp ngoại lệ này một cách thích hợp.

Trạng thái gói thuê bao di động

Trong trường hợp này, bạn cần liên kết chức năng của ứng dụng với một số gói thuê bao dịch vụ di động nhất định trên thiết bị. Ví dụ: bạn có thể có yêu cầu xác minh quyền truy cập vào một số tính năng cao cấp của ứng dụng dựa trên gói thuê bao di động của thiết bị thông qua SIM.

Giá trị nhận dạng nên sử dụng: Subscription ID API để xác định SIM được dùng trên thiết bị.

Mã nhận dạng thuê bao cung cấp một giá trị chỉ mục (bắt đầu từ 1) để xác định duy nhất các SIM đã cài đặt (bao gồm cả SIM vật lý và SIM điện tử) được dùng trên thiết bị. Thông qua mã nhận dạng này, ứng dụng của bạn có thể liên kết chức năng của ứng dụng với nhiều thông tin về gói thuê bao cho một SIM nhất định. Giá trị này ổn định đối với một SIM nhất định, trừ phi thiết bị được đặt lại về trạng thái ban đầu. Tuy nhiên, có thể xảy ra trường hợp cùng một SIM có Mã nhận dạng gói thuê bao khác nhau trên các thiết bị khác nhau hoặc các SIM khác nhau có cùng mã nhận dạng trên các thiết bị khác nhau.

Tại sao có đề xuất này?

Một số ứng dụng có thể hiện đang sử dụng ICCID cho mục đích này. Vì ICC ID là mã nhận dạng duy nhất trên toàn cầu và không thể đặt lại, nên quyền truy cập đã bị hạn chế đối với các ứng dụng có quyền READ_PRIVILEGED_PHONE_STATE kể từ Android 10. Kể từ Android 11, Android đã hạn chế hơn nữa quyền truy cập vào ICCID thông qua API getIccId(), bất kể cấp độ API mục tiêu của ứng dụng. Các ứng dụng bị ảnh hưởng nên di chuyển để sử dụng Mã nhận dạng gói thuê bao.

Đăng nhập một lần

Trong trường hợp này, ứng dụng của bạn cung cấp trải nghiệm đăng nhập một lần, cho phép người dùng liên kết một tài khoản hiện có với tổ chức của bạn.

Giá trị nhận dạng nên dùng: Tài khoản tương thích với trình quản lý tài khoản, chẳng hạn như Liên kết Tài khoản Google

Tại sao có đề xuất này?

Tính năng Liên kết với Tài khoản Google cho phép người dùng liên kết tài khoản Google hiện có của họ với ứng dụng của bạn, mang đến trải nghiệm truy cập liền mạch và an toàn hơn vào các sản phẩm và dịch vụ của tổ chức bạn. Ngoài ra, bạn có thể xác định các phạm vi OAuth tuỳ chỉnh để chỉ chia sẻ dữ liệu cần thiết, từ đó tăng mức độ tin cậy của người dùng bằng cách xác định rõ cách dữ liệu của họ được sử dụng.

Quảng cáo

Nhắm mục tiêu

Trong trường hợp này, ứng dụng của bạn sẽ tạo hồ sơ về mối quan tâm của người dùng để hiển thị cho họ những quảng cáo phù hợp hơn.

Giá trị nhận dạng nên dùng: Nếu ứng dụng của bạn sử dụng một giá trị nhận dạng cho quảng cáo và tải lên hoặc xuất bản lên Google Play, thì giá trị nhận dạng đó phải là Mã nhận dạng cho quảng cáo.

Tại sao có đề xuất này?

Đây là một trường hợp sử dụng liên quan đến quảng cáo, có thể yêu cầu một mã nhận dạng có sẵn trên nhiều ứng dụng của tổ chức bạn, vì vậy, việc sử dụng Mã nhận dạng cho quảng cáo là giải pháp phù hợp nhất. Bạn bắt buộc phải sử dụng Mã nhận dạng cho quảng cáo trong các trường hợp sử dụng quảng cáo, theo Chính sách nội dung dành cho nhà phát triển của Google Play, vì người dùng có thể đặt lại mã nhận dạng này.

Bất kể bạn có chia sẻ dữ liệu người dùng trong ứng dụng hay không, nếu thu thập và sử dụng dữ liệu đó cho mục đích quảng cáo, bạn cần khai báo các mục đích quảng cáo trong Mục An toàn dữ liệu của trang Nội dung ứng dụng trong Play Console.

Đo lường

Trong trường hợp này, ứng dụng của bạn sẽ tạo hồ sơ người dùng dựa trên hành vi của họ trên các ứng dụng của tổ chức bạn trên cùng một thiết bị.

Giá trị nhận dạng nên dùng: API Mã nhận dạng cho quảng cáo hoặc API Play Install Referrer

Tại sao có đề xuất này?

Đây là một trường hợp sử dụng liên quan đến quảng cáo, có thể yêu cầu một mã nhận dạng có sẵn trên nhiều ứng dụng của tổ chức bạn, vì vậy, việc sử dụng Mã nhận dạng cho quảng cáo là giải pháp phù hợp nhất. Nếu bạn sử dụng một mã nhận dạng cho các trường hợp sử dụng quảng cáo, thì mã nhận dạng đó phải là Mã nhận dạng cho quảng cáo vì người dùng có thể đặt lại mã nhận dạng này. Tìm hiểu thêm trong Chính sách nội dung dành cho nhà phát triển trên Google Play.

Lượt chuyển đổi

Trong trường hợp này, bạn đang theo dõi lượt chuyển đổi để phát hiện xem chiến lược tiếp thị của bạn có thành công hay không.

Giá trị nhận dạng nên dùng: API Mã nhận dạng cho quảng cáo hoặc API Play Install Referrer

Tại sao có đề xuất này?

Đây là một trường hợp sử dụng liên quan đến quảng cáo, có thể yêu cầu một mã nhận dạng có sẵn trên nhiều ứng dụng của tổ chức bạn, vì vậy, việc sử dụng Mã nhận dạng cho quảng cáo là giải pháp phù hợp nhất. Bạn bắt buộc phải sử dụng Mã nhận dạng cho quảng cáo trong các trường hợp sử dụng quảng cáo, theo Chính sách nội dung dành cho nhà phát triển của Google Play, vì người dùng có thể đặt lại mã nhận dạng này.

Tái tiếp thị

Trong trường hợp này, ứng dụng của bạn hiển thị quảng cáo dựa trên mối quan tâm trước đây của người dùng.

Giá trị nhận dạng nên sử dụng: Mã nhận dạng cho quảng cáo

Tại sao có đề xuất này?

Đây là một trường hợp sử dụng liên quan đến quảng cáo, có thể yêu cầu một mã nhận dạng có sẵn trên nhiều ứng dụng của tổ chức bạn, vì vậy, việc sử dụng Mã nhận dạng cho quảng cáo là giải pháp phù hợp nhất. Bạn bắt buộc phải sử dụng Mã nhận dạng cho quảng cáo trong các trường hợp sử dụng quảng cáo, theo Chính sách nội dung dành cho nhà phát triển của Google Play, vì người dùng có thể đặt lại mã nhận dạng này.

Phân tích ứng dụng

Trong trường hợp này, ứng dụng của bạn sẽ đánh giá hành vi của người dùng để giúp bạn xác định những điều sau:

  • Những sản phẩm hoặc ứng dụng khác của tổ chức bạn có thể phù hợp với người dùng.
  • Cách thu hút người dùng tiếp tục sử dụng ứng dụng của bạn.
  • Đo lường số liệu thống kê về mức sử dụng và số liệu phân tích cho người dùng đã đăng xuất hoặc người dùng ẩn danh.

Các giải pháp có thể áp dụng:

  • Mã nhóm ứng dụng: Mã nhóm ứng dụng cho phép bạn phân tích hành vi của người dùng trên nhiều ứng dụng mà tổ chức của bạn sở hữu, miễn là bạn không sử dụng dữ liệu người dùng cho mục đích quảng cáo. Nếu đang nhắm đến các thiết bị chạy Dịch vụ Google Play, bạn nên sử dụng Mã nhận dạng nhóm ứng dụng.
  • Mã nhận dạng Firebase (FID): FID được giới hạn trong ứng dụng tạo ra mã nhận dạng này, điều này ngăn không cho mã nhận dạng được dùng để theo dõi người dùng trên các ứng dụng. Bạn cũng có thể dễ dàng đặt lại FID vì người dùng có thể xoá dữ liệu ứng dụng hoặc cài đặt lại ứng dụng. Quy trình tạo FID rất đơn giản; hãy xem hướng dẫn về dịch vụ cài đặt Firebase.

Phát triển ứng dụng

Báo cáo sự cố

Trong trường hợp này, ứng dụng của bạn thu thập dữ liệu về thời điểm và lý do ứng dụng gặp sự cố trên thiết bị của người dùng.

Giá trị nhận dạng nên dùng: FID hoặc mã nhóm ứng dụng

Tại sao có đề xuất này?

FID được giới hạn trong ứng dụng tạo ra nó, điều này ngăn giá trị nhận dạng được dùng để theo dõi người dùng trên các ứng dụng. Bạn cũng có thể dễ dàng đặt lại FID vì người dùng có thể xoá dữ liệu ứng dụng hoặc cài đặt lại ứng dụng. Quy trình tạo FID rất đơn giản; hãy xem hướng dẫn về lượt cài đặt Firebase. Mã nhóm ứng dụng cho phép bạn phân tích hành vi của người dùng trên nhiều ứng dụng thuộc sở hữu của tổ chức, miễn là bạn không sử dụng dữ liệu người dùng cho mục đích quảng cáo.

Báo cáo hiệu suất

Trong trường hợp này, ứng dụng của bạn sẽ thu thập các chỉ số về hiệu suất (chẳng hạn như thời gian tải và mức sử dụng pin) để giúp cải thiện chất lượng của ứng dụng.

Mã nhận dạng nên dùng: Tính năng Giám sát hiệu suất Firebase

Tại sao có đề xuất này?

Tính năng Giám sát hiệu suất của Firebase giúp bạn tập trung vào những chỉ số quan trọng nhất đối với bạn và kiểm thử tác động của một thay đổi gần đây trong ứng dụng.

Thử nghiệm ứng dụng

Trong trường hợp này, ứng dụng của bạn sẽ đánh giá trải nghiệm của người dùng với ứng dụng của bạn cho mục đích kiểm thử hoặc gỡ lỗi.

Giá trị nhận dạng nên dùng: FID hoặc mã nhóm ứng dụng

Tại sao có đề xuất này?

FID được giới hạn trong ứng dụng tạo ra nó, điều này ngăn giá trị nhận dạng được dùng để theo dõi người dùng trên các ứng dụng. Bạn cũng có thể dễ dàng đặt lại FID vì người dùng có thể xoá dữ liệu ứng dụng hoặc cài đặt lại ứng dụng. Quy trình tạo FID rất đơn giản; hãy xem hướng dẫn về lượt cài đặt Firebase. Mã nhóm ứng dụng cho phép bạn phân tích hành vi của người dùng trên nhiều ứng dụng thuộc sở hữu của tổ chức, miễn là bạn không sử dụng dữ liệu người dùng cho mục đích quảng cáo.

Cài đặt trên nhiều thiết bị

Trong trường hợp này, ứng dụng của bạn cần xác định đúng phiên bản của ứng dụng khi ứng dụng được cài đặt trên nhiều thiết bị cho cùng một người dùng.

Giá trị nhận dạng nên sử dụng: FID hoặc GUID

Tại sao có đề xuất này?

FID được thiết kế rõ ràng cho mục đích này; phạm vi của FID bị giới hạn trong ứng dụng để không thể dùng FID theo dõi người dùng trên nhiều ứng dụng và FID sẽ được đặt lại khi người dùng cài đặt lại ứng dụng. Trong một số ít trường hợp khi FID không đủ, bạn cũng có thể sử dụng GUID.

Bảo mật

Phát hiện hành vi sai trái

Trong trường hợp này, bạn đang cố gắng phát hiện nhiều thiết bị giả mạo tấn công các dịch vụ phụ trợ của mình.

Mã nhận dạng nên dùng: Mã thông báo về tính toàn vẹn của API Tính toàn vẹn của Google Play

Tại sao có đề xuất này?

Để xác minh rằng một yêu cầu đến từ một thiết bị Android chính hãng (thay vì một trình mô phỏng hoặc mã khác giả mạo một thiết bị khác), hãy sử dụng API Tính toàn vẹn của Google Play.

Gian lận trong quảng cáo

Trong trường hợp này, ứng dụng của bạn sẽ kiểm tra để đảm bảo rằng các lượt hiển thị và hành động của người dùng trong ứng dụng là chính thống và có thể xác minh.

Giá trị nhận dạng nên sử dụng: Mã nhận dạng cho quảng cáo

Tại sao có đề xuất này?

Bạn bắt buộc phải sử dụng Mã nhận dạng cho quảng cáo trong các trường hợp sử dụng quảng cáo, theo Chính sách nội dung dành cho nhà phát triển của Google Play, vì người dùng có thể đặt lại mã nhận dạng này.

Quản lý quyền kỹ thuật số (DRM)

Trong trường hợp này, ứng dụng của bạn muốn bảo vệ quyền truy cập gian lận vào tài sản trí tuệ hoặc nội dung trả phí.

Giá trị nhận dạng nên dùng: Việc sử dụng FID hoặc GUID buộc người dùng phải cài đặt lại ứng dụng để tránh các giới hạn về nội dung. Đây là một gánh nặng đủ lớn để ngăn chặn hầu hết mọi người. Nếu biện pháp này không đủ để bảo vệ, Android cung cấp một API DRM. API này có thể dùng để hạn chế quyền truy cập vào nội dung, bao gồm cả mã nhận dạng cho mỗi APK, tức là Widevine ID.

Tùy chọn của người dùng

Trong trường hợp này, ứng dụng của bạn sẽ lưu trạng thái người dùng trên mỗi thiết bị, đặc biệt là đối với những người dùng chưa đăng nhập. Bạn có thể chuyển trạng thái này sang một ứng dụng khác được ký bằng cùng một khoá trên cùng một thiết bị.

Giá trị nhận dạng nên sử dụng: FID hoặc GUID

Tại sao có đề xuất này?

Bạn không nên duy trì thông tin khi cài đặt lại vì người dùng có thể muốn đặt lại các lựa chọn ưu tiên bằng cách cài đặt lại ứng dụng.