Trang này được dịch bởi Cloud Translation API.

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 thích 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 chung về các quyền trên Android, hãy xem bài viết Tổng quan về quyền. Để biết các phương pháp cụ thể hay nhất khi làm việc với các quyền trên Android, hãy xem phần 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 trên 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 đây:

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 sử dụng các giá trị nhận dạng khác với mã nhận dạng phần cứng không đặt lại được.
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ã nhận dạng thiết bị di động quốc tế (IMEI) mà không giới hạn các 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à một ứng dụng của 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ó READ_PRIVILEGED_PHONE_STATE quyền đặc quyền để truy cập vào các giá trị nhận dạng này.
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 việc này khi có sự đồng ý rõ ràng của người dùng.
Không cầu nối việc đặt lại mã nhận dạng cho quảng cáo.
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 mọi trường hợp sử dụng khác, ngoại trừ mục đích ngăn chặn gian lận thanh toán và qua đ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 có FID hoặc GUID là đủ.
Dùng API phù hợp với trường hợp sử dụng của bạn để giảm thiểu rủi ro về quyền riêng tư. Dùng API DRM để 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 mà không gây ra rủi ro về quyền riêng tư hay không.

Các phần còn lại của hướng dẫn này trình bày chi tiết về các 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à 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, khi bạn sử dụng mã nhận dạng này, hãy lưu ý một số điểm chính sau:

Luôn tôn trọng ý định của người dùng trong việc đặt lại mã nhận dạng cho quảng cáo. Đừng kết nối các thao tác đặ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 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 nội dung dành cho nhà phát triển trên Google Play nêu rõ những điều sau:

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

"...bạn phải tuân thủ chế độ cài đặt "Chọn không tham gia 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 thì bạn không thể sử dụng giá trị 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."

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

Ngoài ra, hãy lưu ý rằng Chính sách nội dung dành cho nhà phát triển trên Google Play yêu cầu "không được 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 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 sẵn các bảng cơ sở dữ liệu bằng các cột sau:

BẢNG-01
`timestamp`	`ad_id`	`account_id`	`clickid`
BẢNG-02
`account_id`	`name`	`dob`	`country`

Trong ví dụ này, cột ad_id có thể được kết hợp với PII thông qua cột account_id ở 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 trên Google Play nếu bạn không nhận được sự cho phép rõ ràng từ người dùng của mình.

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. Có thể có "mã nhận dạng gần như" xuất hiện trong cả bảng có khoá PII và Mã quảng cáo. Điều này cũng gây ra sự cố. Ví dụ: giả sử chúng tôi thay đổi TABLE-01 và TABLE-02 như sau:

BẢNG-01
`timestamp`	`ad_id`	`clickid`	`dev_model`
BẢNG-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, bạn vẫn có thể kết hợp 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 như như vậy tồn tại 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 khái quát hoá dữ liệu riêng biệ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 ở mọi dấu thời gian.

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

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. Trong ví dụ đầu tiên ở trên, điều này có nghĩa là bạn không đưa cột account_id vào TABLE-01.
Tách biệt và giám sát danh sách kiểm soát quyền truy cập đối với những người dùng hoặc vai trò có quyền truy cập vào cả dữ liệu khoá và thông tin nhận dạng cá nhân (PII) cho Mã nhận dạng cho quảng cáo. 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 liên kết 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à PII. Nhìn chung, việc kiểm soát quyền truy cập nghĩa là thực hiện những việc sau:
1. Giữ tách biệt danh sách kiểm soát quyền truy cập (ACL) cho dữ liệu có khoá của Mã nhận dạng nhà quảng cáo và PII để giảm thiểu số lượng cá nhân hoặc vai trò trong 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ý 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 làm việc có trách nhiệm với mã nhận dạng cho quảng cáo, hãy xem Tài liệu tham khảo 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 phần lớn 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 phép mới có thể truy cập vào giá trị nhận dạng này. Đồng thời, bạn có thể dễ dàng đặt lại mã này (tương đối) vì mã chỉ tồn tại trong thời gian cài đặt ứng dụng.

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

Trong trường hợp FID không thiết thực, bạn cũng có thể sử dụng các mã nhận dạng duy nhất trên toàn cầu (GUID) tuỳ chỉnh để xác định riêng biệt một thực thể ứng dụng. Cách đơn giản nhất để thực hiện việc này là tạo GUID riêng của 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 là duy nhất trên toàn hệ thống, nên bạn có thể dùng giá trị này để xác định một thực thể ứng dụng cụ thể. Để tránh các mối lo ngại liên quan đến việc liên kết giá trị nhận dạng trên nhiều ứng dụng, hãy lưu trữ GUID vào 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 sử dụng địa chỉ MAC

Địa chỉ MAC là duy nhất trên toàn hệ thống, người dùng không thể đặt lại được và vẫn tồn tại 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, chỉ các ứng dụng hệ thống mới có thể truy cập vào địa chỉ MAC. Các ứng dụng bên thứ ba không thể truy cập vào đó.

Các thay đổi về khả năng sử dụng địa chỉ MAC trên Android 11

Trên các ứng dụng nhắm đến Android 11 trở lên, việc tạo ngẫu nhiên MAC cho các mạng Passpoint là theo mỗi hồ sơ Passpoint, sẽ 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)
Vùng
Thông tin xác thực, dựa trên thông tin đăng nhập 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 xác thực 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ỉ hiển thị giao diện mạng có địa chỉ IP. Đ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 RTM_GETLINK thông báo Netlink.

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

NetworkInterface.getHardwareAddress() trả về giá trị rỗng cho mọi giao diện.
Ứng dụng không thể 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.

Lưu ý rằng hầu hết nhà phát triển nên sử dụng các 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 ổ cắm Netlink. Ví dụ: một ứng dụng cần cập nhật thông tin về các tuyến hiện tại có thể nhận thông tin này bằng cách theo dõi các thay đổi về mạng thông qua ConnectivityManager.registerNetworkCallback() và gọi LinkProperties.getRoutes() được liên kết của mạng.

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

Hệ điều hành Android cung cấp một số mã nhận dạng với nhiều đặc điểm hành vi. Mã nhận dạng bạn nên sử dụng phụ thuộc vào cách các đặc điểm sau đây hoạt động trong trường hợp sử dụng của bạn. Tuy nhiên, những đặc điểm này cũng đi kèm với các hệ quả về quyền riêng tư. Vì vậy, bạn cần hiểu cách các đặ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ó 3 phiên bản:

Một ứng dụng: Đây là mã nhận dạng nội bộ đối với ứng dụng và các ứng dụng khác không thể truy cập vào mã nhận dạng này.
Nhóm ứng dụng: Một nhóm các ứng dụng có 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ả cá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ấp cho một giá trị nhận dạng càng rộng thì càng có nhiều nguy cơ dùng giá trị đó cho mục đích theo dõi. Ngược lại, nếu chỉ có một thực thể ứng dụng duy nhất có thể truy cập giá trị nhận dạng, thì bạn không thể sử dụng giá trị nhận dạng đó để theo dõi thiết bị qua các giao dịch trong các ứng dụng khác nhau.

Khả năng đặt lại và tính bền vững

Khả năng đặt lại và tính ổn định xác định thời gian tồn tại 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 điều kiện kích hoạt đặt lại phổ biến bao gồm: đặt lại trong ứng dụng, đặt lại thông qua Cài đặt hệ thống, đặt lại khi khởi chạy và đặt lại khi cài đặt. 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 mã nhận dạng:

Chỉ phiên: 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.
Lượt cài đặt-đặt lại: Một mã nhận dạng mới được sử 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ã 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.
Liên tục FDR: Mã nhận dạng vẫn tồn tại sau khi đặt lại về trạng thái ban đầu.

Với khả năng đặt lại, người dùng có thể tạo một mã nhận dạng mới được huỷ liên kết với mọi thông tin hồ sơ hiện có. Giá trị nhận dạng duy trì càng lâu và đáng tin cậy, chẳng hạn như giá trị vẫn tồn tại khi đặt lại về trạng thái ban đầu, thì nguy cơ người dùng có thể bị theo dõi trong thời gian dài càng lớn. Nếu giá trị nhận dạng được đặt lại sau khi cài đặt lại ứng dụng, điều này sẽ làm giảm thời gian lưu trữ và cung cấp cách thức để đặt lại mã nhận dạng, ngay cả khi người dùng không có quyền kiểm soát rõ ràng để đặt lại mã đó 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 sẽ tạo ra khả năng xung đột; tức là các giá trị nhận dạng giống hệt nhau tồn tại trong phạm vi được liên kết. Ở cấp cao nhất, giá trị nhận dạng duy nhất trên toàn hệ thống 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 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 đối với các giá trị nhận dạng ngẫu nhiên được sao chép vào ngày cài đặt (chẳng hạn như 2019-03-01) sẽ cao hơn nhiều so với giá trị nhận dạng được chèn vào dấu thời gian cài đặt Unix (chẳng hạn như 1551414181).

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

Bảo vệ tính toàn vẹn và khả năng không trả lời

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 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 mà kẻ gửi tin nhắn rác sử dụng. Giá trị nhận dạng khó giả mạo cũng mang đến khả năng không bị giả mạo. Nếu thiết bị ký một thông báo bằng khoá bí mật, thì bạn khó có thể xác nhận rằng thiết bị của người khác đã gửi tin nhắn đó. Khả năng không thể xác nhận 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 họ rất tiếc.

Các trường hợp sử dụng phổ biến và mã nhận dạng thích 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 các mã này và các mã này chỉ thuộc phạm vi của thiết bị. Trong nhiều trường hợp, bạn chỉ cần một giá trị nhận dạng trong 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 tương tác với chức năng nhắn tin và điện thoại của thiết bị thông qua tài khoản của nhà mạng.

Mã nhận dạng nên dùng: IMEI, IMSI và Line1

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

Chúng tôi chấp nhận việc sử dụng giá trị nhận dạng phần cứng nếu đó 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 cắm SIM hoặc để gửi tin nhắn SMS qua IP (đối với Dòng 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 quyền, bạn nên sử dụng tính năng đăng nhập vào tài khoản để truy xuất thông tin thiết bị của người dùng phía máy chủ. Lý do cho việc này 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 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 nên xử lý các trường hợp ngoại lệ này một cách linh hoạt.

Trạng thá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 trên thiết bị. Ví dụ: có thể bạn cần phải 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ị qua SIM.

Giá trị nhận dạng nên dùng: API Mã gói thuê bao để xác định các SIM được dùng trên thiết bị.

Mã gói thuê bao cung cấp một giá trị chỉ mục (bắt đầu từ 1) để xác định duy nhất SIM đã cài đặt (bao gồm cả SIM thực và SIM điện tử) 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 mình với nhiều thông tin thuê bao của một SIM nhất định. Giá trị này không thay đổi đố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 những trường hợp mà cùng một SIM có một Mã gói thuê bao khác trên các thiết bị khác nhau hoặc các SIM khác nhau có cùng một mã 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 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, 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 sẽ 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 nên di chuyển để sử dụng Mã 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 sẽ 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 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 họ 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 phạm vi OAuth tuỳ chỉnh để chỉ chia sẻ dữ liệu cần thiết, giúp tăng độ 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 để cho họ thấy 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 dùng mã nhận dạng cho các quảng cáo và nội dung tải lên hoặc xuất bản lên Google Play, thì mã đó phải là 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. Vì vậy, bạn có thể cần phải có mã nhận dạng trên các ứ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 thích hợp nhất. Theo Chính sách nội dung dành cho nhà phát triển trên Google Play, việc sử dụng mã nhận dạng cho quảng cáo là bắt buộc đối với 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ể 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 mục đích quảng cáo tại 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ơ của người dùng dựa trên hành vi của họ trong 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 được đề 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 trên Play

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. Vì vậy, bạn có thể cần phải có mã nhận dạng trên các ứ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 thích 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ã đó phải là mã nhận dạng cho quảng cáo vì người dùng có thể đặt lại. 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 mình có thành công hay không.

Giá trị nhận dạng được đề 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 trên Play

Tại sao có đề xuất 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 các mối quan tâm trước đây của người dùng.

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

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

Phân tích ứng dụng

Trong trường hợp này, ứng dụng 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 có thể phù hợp với người dùng.
Cách duy trì sự quan tâm của người dùng đối với việc sử dụng ứng dụng của bạn.
Đo lường số liệu thống kê về việc sử dụng và số liệu phân tích cho 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 dùng dữ liệu người dùng cho mục đích quảng cáo. Nếu đang nhắm mục tiêu đến các thiết bị do Dịch vụ Google Play cung cấp, bạn nên sử dụng Mã nhóm ứng dụng.
Mã nhận dạng Firebase (FID): FID được xác định trong phạm vi ứng dụng tạo ra mã, ngăn chặ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. Bạn cũng có thể dễ dàng đặt lại mã này 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 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 sẽ 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 nằm trong phạm vi ứng dụng tạo ra nó, ngăn sử dụng giá trị nhận 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 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.

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.

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 các chỉ số quan trọng nhất với bạn, đồng thời kiểm tra tác động của một thay đổi gần đây đối với ứng dụng của bạn.

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 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?

Lắp đặt trên nhiều thiết bị

Trong trường hợp này, ứng dụng cần xác định đúng thực thể 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 được giới hạn ở ứng dụng nên không thể dùng để theo dõi người dùng trên các ứng dụng và FID sẽ được đặt lại khi 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ả đ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 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 yêu cầu đến từ một thiết bị Android thực – 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 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 xác và có thể xác minh được.

Giá trị nhận dạng nên 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 trên Google Play, việc sử dụng mã nhận dạng cho quảng cáo là bắt buộc đối với 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í.

Giá trị nhận dạng được đề xuất nên sử dụng: Việc sử dụng FID hoặc GUID sẽ buộc người dùng cài đặt lại ứng dụng để tránh giới hạn nội dung. Đây là một gánh nặng đủ để răn đe hầu hết mọi người. Nếu khả năng bảo vệ này không đủ, Android sẽ cung cấp DRM API có thể 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 tệp APK là mã nhận dạng Widevine.

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

Trong trường hợp này, ứng dụng sẽ lưu trạng thái người dùng trên mỗi thiết bị trên ứng dụng, đặ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 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 thông qua các lần cài đặt lại vì có thể người dùng 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.