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 dựa trên trường hợp sử dụng của bạn.

Để biết thông tin chung về các quyền trên Android, hãy xem bài viết Quyền tổng quan. Để đạt được kết quả tốt nhất các phương pháp để xử lý quyền trên 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 để làm việc với giá trị nhận dạng Android

Để bảo vệ quyền riêng tư của người dùng, hãy sử 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:

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ể thực hiện được hầu hết các trường hợp sử dụng ngay cả khi ứng dụng dùng các giá trị nhận dạng khác mã 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 bằng cách sử dụng mã nhận dạng phần cứng, chẳng hạn như Thông tin nhận dạng thiết bị di động quốc tế (IMEI), không giới hạn chức năng cần thiết.

   Android 10 (API cấp 29) thêm các quy định 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ó quyền đặc biệt của nhà mạng hoặc có quyền đặc quyền READ_PRIVILEGED_PHONE_STATE để 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ề việc theo dõi quảng cáo. Nếu bạn phải kết nối mã 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 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ã 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 quyền riêng tư rủi ro. Sử dụng API DRM cho tính năng 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ị chính hãng hay không mà không gây 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 trình bày chi tiết về những quy tắc này trong bối cảnh đang phát triển các ứ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, có một số điểm chính cần lưu ý khi bạn sử dụng Mã nhận dạng:

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 đặt lại người dùng bằng cách sử dụng một giá trị nhận dạng hoặc vân tay khác để liên kết các mã nhận dạng cho quảng cáo tiếp theo cùng nhau mà không sự đồng ý 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 nêu rõ những điều sau:

"...nếu đặt lại, bạn không được kết nối mã nhận dạng cho quảng cáo mới này 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 tuân thủ 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 là có thể định cấu hình, trong đó người dùng có thể giới hạn số lượng theo dõi được liên kết với Mã nhận dạng. Luôn sử dụng AdvertisingIdClient.Info.isLimitAdTrackingEnabled() để đảm bảo rằng bạn không tránh né người dùng mong muốn. Nhóm Google Nội dung dành cho nhà phát triển trên Google Play Chính sách nêu rõ sau:

"...bạn phải tuân theo 'Chọn không tham gia quảng cáo dựa trên sở thích' của người dùng hoặc "Chọn không sử dụng chế độ cá nhân hoá quảng cáo" cài đặt. Nếu người dùng đã bật cài đặt này, bạn không được sử dụng mã nhận dạng cho quảng cáo để tạo hồ sơ người dùng cho quảng cáo hoặc 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".

Nắm rõ mọi chính sách về quyền riêng tư hoặc bảo mật liên quan đến 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ả chính sách hiện hành về SDK Analytics.

Ngoài ra, xin lưu ý rằng Nội dung dành cho nhà phát triển trên Google Play Chính sách yêu cầu không được liên kết Mã nhận dạng cho quảng cáo "với mã nhận dạng cá nhân hoặc được liên kết với bất kỳ mã nhận dạng thiết bị cố định nào (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 bằng các cột sau:

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

Xin lưu ý rằng mối liên kết giữa Mã nhận dạng nhà quảng cáo và PII không phải lúc nào 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ả PII và Các bảng có khoá 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:

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

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

Sau đây là một số giải pháp khác:

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

• Tách biệt 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á bằng Mã nhận dạng cho quảng cáo và PII. Bằng cách kiểm soát và kiểm soát chặt chẽ khả năng truy cập vào cả hai nguồn cùng một lúc (ví dụ: bằng cách kết hợp giữa các bảng), bạn sẽ giảm rủi ro về mối liên kết giữa Mã nhận dạng cho quảng cáo và PII. Nói chung, việc kiểm soát quyền truy cập có nghĩa là làm những việc sau:

  1. Giữ danh sách kiểm soát quyền truy cập (ACL) cho dữ liệu đã khóa ID 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ả hai Danh sách kiểm soát quyền truy cập (ACL).
  2. Triển khai tính năng ghi nhật ký truy cập và kiểm tra để 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ã cài đặt Firebase (FID). Đây là giải pháp được đề xuất trong hầu hết các trường hợp sử dụng không phải quảng cáo. Chỉ thực thể ứng dụng được cấp quyền truy cập mới có thể truy cập vào giá trị nhận dạng này và giá trị nhận dạng này (tương đối) dễ dàng được đặt lại vì giá trị nhận dạng này chỉ tồn tại 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 ở phạm vi thiết bị và không thể đặt lại. Để biết thêm thông tin, hãy xem firebase.installations Tài liệu tham khảo API.

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

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

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

Do mã nhận dạng là duy nhất trên toàn hệ thống, nên mã nhận dạng này có thể được dùng để xác định một mã nhận dạng cụ thể bản sao ứng dụng. Để tránh những mối lo ngại liên quan đến việc liên kết giá trị nhận dạng trên các ứng dụng, lưu trữ các 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ề lưu trữ 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, không phải do người dùng đặ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ỉ dành cho các ứng dụng hệ thống. Ứng dụng bên thứ ba không thể truy cập vào các tính năng đó.

Thay đổi về khả năng sử dụng địa chỉ MAC trong Android 11

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

• Tên miền đủ điều kiện (FQDN)
• Realm
• Chứng chỉ danh tính, dựa trên thông tin đăng nhập được sử dụng trong hồ sơ Passpoint:
  • Thông tin đăng nhập người dùng: tên người dùng
  • Thông tin xác thực chứng chỉ: loại 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 sẽ không thể truy cập vào địa chỉ MAC của thiết bị; chỉ giao diện mạng kèm địa chỉ IP đều có thể thấy được. Điều này ảnh hưởng đến getifaddrs() và NetworkInterface.getHardwareAddress() cũng như gửi RTM_GETLINK thông báo Netlink.

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

• NetworkInterface.getHardwareAddress() trả về giá trị rỗng cho mọi giao diện.
• Ứng dụng không thể sử dụng hàm bind() trên ổ cắm NETLINK_ROUTE.
• Lệnh ip không trả về thông tin về 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 các nhà phát triển nên sử dụng API cấp cao hơn của ConnectivityManager thay vì các API cấp thấp hơn như NetworkInterface! getifaddrs()! hoặc Netlink. Ví dụ: một ứng dụng cần thông tin mới nhất về các tuyến 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 ConnectivityManager.registerNetworkCallback() và gọi LinkProperties.getRoutes() 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ác đặc điểm hành vi khác nhau. Mã nhận dạng bạn nên sử dụng phụ thuộc vào cách hoạt động của các đặc điểm sau đây trường hợp sử dụng của bạn. Tuy nhiên, những đặc điểm này cũng có những tác động đến 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 giá trị nhận dạng giải thích những hệ thống nào có thể truy cập vào giá trị nhận dạng đó. Phạm vi giá trị nhận dạng Android thường có ba 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ột nhóm ứng dụng liên quan được xác định trước có thể truy cập vào mã nhận dạng này.
• 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ã 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 đó được sử dụng cho mục đích theo dõi càng lớn. Ngược lại, nếu một giá trị nhận dạng chỉ có thể được truy cập bằng một thực thể ứng dụng duy nhất, thì bạn không thể sử dụng giá trị nhận 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à lưu trữ cố định

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

• Chỉ phiên: Mã mới được sử dụng mỗi khi người dùng khởi động lại ứng dụng.
• Cài đặt lại: Một mã nhận dạng mới được dùng mỗi khi người dùng gỡ cài đặt rồi cài đặt lại ứng dụng.
• Đặt lại FDR: Một mã nhận dạng mới được sử dụng mỗi khi người dùng đặt lại thiết bị về trạng thái ban đầu.
• Vĩnh viễn FDR: Mã nhận dạng vẫn tồn tại khi đặt lại về trạng thái ban đầu.

Tính 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. Giá trị nhận dạng càng tồn tại lâu và đá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ì càng có nhiều nguy cơ người dùng bị theo dõi lâu dài. Nếu mã nhận dạng được đặt lại khi cài đặt lại ứng dụng, điều này làm giảm tính ổn định và cung cấp cách thức để đặt lại mã nhận dạng, ngay cả khi không có thông tin người dùng rõ ràng để đặt lại mật khẩu từ trong ứng dụng hoặc phần Cài đặt hệ thống.

Điểm đặc biệt

Tính duy nhất thiết lập khả năng va chạm; tức là, giống hệt có sẵn trong phạm vi được liên kết. Ở cấp độ cao nhất, toàn cầu mã nhận dạng duy nhất không bao giờ 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 ra nó. Ví dụ: cơ hội xung đột cao hơn nhiều đối với các giá trị nhận dạng ngẫu nhiên bắt nguồn cùng với ngày theo lịch lượt cài đặt (chẳng hạn như 2019-03-01) so với những giá trị nhận dạng bắt nguồn từ Unix dấu thời gian cài đặt (chẳng hạn như 1551414181).

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

Bảo vệ tính toàn vẹn và khả năng chống chịu

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ị này không phải là thiết bị ảo bị người gửi nội dung rác sử dụng. Các giá trị nhận dạng khó giả mạo cũng mang lại khả năng không thể phản đối. Nếu thiết bị ký thư bằng một khoá bí mật, thì rất khó để xác nhận rằng thiết bị đã gửi tin nhắn. Khả năng không chịu trách nhiệm có thể là điều mà người dùng muốn, chẳng hạn như chẳng hạn như khi xác thực một khoản thanh toán hoặc đó có thể là một tài sản không mong muốn, chẳng hạn như cũng như khi họ gửi một bức thư mà họ hối tiếc.

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

Phần này cung cấp các phương á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ỉ dành cho thiết bị. Trong nhiều trường hợp, bạn chỉ cần nhập một giá trị nhận dạng ở phạm vi ứng dụng là đủ.

Tài khoản

Trạng thái nhà mạng

Trong trường hợp này, ứng dụng của bạn sẽ tương tác với điện thoại và tính năng nhắn tin của thiết bị thông qua tài khoản nhà mạng.

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

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 đây là yêu cầu bắt buộc đối với 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 SIM, hoặc để phân phối tin nhắn SMS qua IP (đối với Đường dây 1) – 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, chúng tôi khuyên bạn nên sử dụng thông tin đăng nhập 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 cho điều này là trong Android 6.0 (API cấp 23) và cao hơn, thì bạn chỉ có thể sử dụng các giá trị nhận dạng này thông qua quyền khi bắt đầu 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ý các trường hợp ngoại lệ này một cách linh hoạt.

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ố các gói đăng ký dịch vụ trên thiết bị. Ví dụ: bạn có thể 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: API mã thuê bao để xác định các thẻ SIM được sử dụng trên thiết bị.

Mã 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 thẻ SIM đã cài đặt (bao gồm cả thẻ SIM vật lý và điện tử) được sử dụng trên thiết bị. Thông qua ID này, ứng dụng của bạn có thể liên kết chức năng của nó với thông tin gói thuê bao của một SIM cụ thể. 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ể có trường hợp cùng một thẻ SIM có mã thuê bao khác nhau trên các thiết bị hoặc các thẻ SIM khác nhau có cùng một mã trên các thiết bị.

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

Một số ứng dụng có thể đang sử dụng Mã nhận dạng ICC cho mục đích này. Vì mã ICC là 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ế thêm 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 cần di chuyển sang hãy 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 mình.

Giá trị nhận dạng đề xuất nên sử dụng: Tài khoản tương thích với người 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 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 người dùng với ứng dụng của bạn, giúp bạn truy cập liền mạch và an toàn hơn vào của tổ chức. Ngoài ra, bạn có thể xác định phạm vi OAuth tuỳ chỉnh chỉ chia sẻ dữ liệu cần thiết, nâng cao lòng tin 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ọ quảng cáo phù hợp hơn.

Giá trị nhận dạng nên sử dụng: Nếu ứng dụng của bạn sử dụng mã nhận dạng cho quảng cáo và tải lên hoặc phát hành lên Google Play, thì mã 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 bạn cung cấp giấy tờ tuỳ thân trên các ứng dụng khác nhau của tổ chức, nên việc sử dụng mã nhận dạng cho quảng cáo phù hợp nhất. Theo Chính sách nội dung dành cho nhà phát triển của Google Play, bạn bắt buộc phải sử dụng Mã nhận dạng cho quảng cáo cho các trường hợp sử dụng quảng cáo vì người dùng có thể đặt lại mã 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 bạn 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 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ơ cho người dùng dựa trên hành vi của họ cho các ứng dụng của tổ chức trên cùng một thiết bị.

Giá trị nhận dạng đề xuất nên sử dụng: Mã nhận dạng cho quảng cáo hoặc API liên kết giới thiệu lượt cài đặt của Play

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 bạn cung cấp giấy tờ tuỳ thân trên các ứng dụng khác nhau của tổ chức, nên việc sử dụng mã nhận dạng cho quảng cáo phù hợp nhất. Nếu bạn sử dụng 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 đó. Tìm hiểu thêm trong Chính sách nội dung dành cho nhà phát triển của 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 mình có thành công hay không.

Giá trị nhận dạng đề xuất nên sử dụng: Mã nhận dạng cho quảng cáo hoặc API liên kết giới thiệu lượt cài đặt của Play

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 bạn cung cấp giấy tờ tuỳ thân trên các ứng dụng khác nhau của tổ chức, nên việc sử dụng mã nhận dạng cho quảng cáo phù hợp nhất. Theo Chính sách nội dung dành cho nhà phát triển của Google Play, bạn bắt buộc phải sử dụng Mã nhận dạng cho quảng cáo cho các trường hợp sử dụng quảng cáo vì người dùng có thể đặt lại mã 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.

Mã nhận dạng đề xuất 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à trường hợp sử dụng liên quan đến quảng cáo có thể yêu cầu mã nhận dạng có sẵn trên nhiều ứng dụng của tổ chức. 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. Theo Chính sách nội dung dành cho nhà phát triển của Google Play, bạn bắt buộc phải sử dụng Mã nhận dạng cho quảng cáo cho các trường hợp sử dụng quảng cáo vì người dùng có thể đặt lại mã 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:

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

Các giải pháp khả thi bao gồm:

• 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 bạn đang nhắm mục tiêu đến các thiết bị do Google Play cung cấp của Google, bạn nên sử dụng Mã nhóm ứng dụng.
• Mã Firebase (FID): FID được giới hạn trong phạm vi ứng dụng tạo ra mã này ngăn việc sử dụng giá trị nhận dạng để theo dõi người dùng trên các ứng dụng. Ngoài ra dễ dàng đặt lại vì người dùng có thể xoá dữ liệu ứng dụng hoặc cài đặt lại ứng dụng. Chiến lược phát hành đĩa đơn quy trình tạo FID rất đơn giản; xem các lượt cài đặt Firebase của chúng tôi.

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 sẽ thu thập dữ liệu về thời điểm và nguyên nhân khiến ứ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 giá trị nhận dạng này, nhờ đó ngăn việc sử dụng giá trị nhận dạng để theo dõi người dùng trên các ứng dụng. Nhãn cũng có thể đặt lại dễ dàng, vì người dùng có thể xóa dữ liệu ứng dụng hoặc cài đặt lại ứng dụng. Quá trình tạo FID đơn giản; xem Hướng dẫn 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 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 để 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ố 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.

Giá trị nhận dạng nên dù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 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 sẽ đánh giá trải nghiệm của người dùng khi sử dụng ứng dụng để kiểm thử hoặc mục đích 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 giá trị nhận dạng này, nhờ đó ngăn việc sử dụng giá trị nhận dạng để theo dõi người dùng trên các ứng dụng. Nhãn cũng có thể đặt lại dễ dàng, vì người dùng có thể xóa dữ liệu ứng dụng hoặc cài đặt lại ứng dụng. Quá trình tạo FID đơn giản; xem Hướng dẫn 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 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.

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 đượ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 chỉ giới hạn ở ứng dụng nên không thể dùng để 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 đang tấn công các dịch vụ phụ trợ của mình.

Giá trị 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 thực—chứ không phải một yêu cầu 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 sẽ kiểm tra để đảm bảo lượt hiển thị và hành động của người dùng trong ứng dụng của bạn. đều thật và có thể xác minh được.

Mã nhận dạng đề xuất nên sử dụng: Mã nhận dạng cho quảng cáo

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

Theo Chính sách nội dung dành cho nhà phát triển của Google Play, 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 vì người dùng có thể đặt lại mã 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 có tính phí.

Mã nhận dạng nên sử 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 cản hầu hết mọi người. Nếu biện pháp này không đủ khả năng bảo vệ, Android cung cấp API DRM. API này có thể được dùng để giới hạn quyền truy cập vào nội dung, bao gồm giá trị nhận dạng cho mỗi APK, Mã Widevine.

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 chính 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 lưu giữ thông tin bằng cách cài đặt lại vì người dùng có thể muốn đặt lại tùy chọn của họ bằng cách cài đặt lại ứng dụng.