Báo cáo phân bổ: đo lường trên web và ứng dụng

Nội dung cập nhật gần đây

• Đã thêm một mục trên báo cáo gỡ lỗi chuyển đổi
• Đã thêm hướng dẫn về cách tham gia danh sách cho phép để đăng ký các nguồn trên web

Như đã mô tả trong đề xuất thiết kế Attribution Reporting API, API cho phép phân bổ các đường dẫn kích hoạt sau trên một thiết bị chạy Android:

• Ứng dụng với ứng dụng: Người dùng thấy quảng cáo trong ứng dụng, sau đó chuyển đổi trong ứng dụng đó hoặc một ứng dụng khác đã cài đặt.
• Ứng dụng với web: Người dùng thấy quảng cáo trong ứng dụng, sau đó chuyển đổi trên thiết bị di động hoặc trình duyệt ứng dụng.
• Web với ứng dụng: Người dùng thấy quảng cáo trong trình duyệt ứng dụng hoặc thiết bị di động, sau đó chuyển đổi trong ứng dụng.
• Web với web: Người dùng thấy quảng cáo trong trình duyệt ứng dụng hoặc thiết bị di động, sau đó chuyển đổi trong cùng một trình duyệt hoặc trình duyệt khác trên cùng một thiết bị.

Web ở đây được định nghĩa là nội dung web hiển thị trong một ứng dụng. Nội dung web có thể xuất hiện trong ngữ cảnh của một ứng dụng trình duyệt trên thiết bị di động, hoặc dưới dạng trang web được nhúng trong các ứng dụng không phải trình duyệt.

Các đường dẫn kích hoạt ở trên đòi hỏi phải đáp ứng các yêu cầu sau:

• Đối với công nghệ quảng cáo: cập nhật các lệnh gọi API và báo cáo để cho phép các đường dẫn từ ứng dụng đến web
• Đối với ứng dụng và trình duyệt: khả năng truyền thông tin đăng ký các nguồn phân bổ web và trình kích hoạt web tới Android

Tài liệu này giải thích cách Attribution Reporting API được mở rộng để hỗ trợ đường dẫn kích hoạt từ ứng dụng đến web, từ web đến ứng dụng và giữa các trang web. Hướng dẫn này cũng mô tả những thay đổi mà công nghệ quảng cáo và ứng dụng cần thực hiện để đáp ứng yêu cầu hỗ trợ các đường dẫn kích hoạt này.

Truy cập vào Attribution Reporting API

Các nền tảng công nghệ quảng cáo cần đăng ký để truy cập vào Attribution Reporting API. Hãy xem bài viết Đăng ký tài khoản Hộp cát về quyền riêng tư để biết thêm thông tin.

Sau khi hoàn tất quá trình đăng ký, API sẽ huỷ việc đăng ký nếu nhận được lệnh gọi huỷ đăng ký.

Khi đăng ký, các nền tảng công nghệ quảng cáo phải đảm bảo việc đăng ký với tất cả URL máy chủ có thể sử dụng trên ứng dụng và web để đăng ký các nguồn và trình kích hoạt phân bổ. Nhiều URL đăng ký máy chủ được hỗ trợ, nhưng chỉ một nguồn gốc báo cáo được hỗ trợ. Nguồn báo cáo này được lấy từ miền của một trong các URL đăng ký máy chủ.

Các thay đổi đối với công nghệ quảng cáo

Phần này thảo luận về những thay đổi đối với các công nghệ quảng cáo sử dụng Attribution Reporting API.

Các thay đổi đối với việc đăng ký và phân bổ

Khi đăng ký nguồn phân bổ, các công nghệ quảng cáo chỉ định một trường đích là tên gói ứng dụng nơi sự kiện kích hoạt xảy ra. Để cho phép tính năng đo lường ứng dụng trên web, chúng tôi dự định hỗ trợ một trường đích của ứng dụng (tên gói ứng dụng) và một trường đích của web (eTLD+1).

Khi đăng ký nguồn hoặc trình kích hoạt phân bổ web, API này không hỗ trợ lệnh chuyển hướng vì mỗi ứng dụng lưu trữ nội dung web có thể có mô hình quản lý quyền riêng. Mỗi ứng dụng chịu trách nhiệm theo dõi các lệnh chuyển hướng (nếu được hỗ trợ) và gọi API ngữ cảnh web cho mỗi bước chuyển hướng.

Ngoài ra, việc tích hợp này cho phép các công nghệ quảng cáo sử dụng logic phân bổ dành riêng cho ứng dụng trên các nguồn phân bổ web. Chẳng hạn như bạn hiện có thể chỉ định thời lượng phân bổ sau cài đặt trên một nguồn phân bổ web.

Nhận báo cáo sử dụng web và ứng dụng

Attribution Reporting API của Android có thể gửi báo cáo cho cả lượt chuyển đổi trên web và trong ứng dụng. Nếu không muốn căn chỉnh dữ liệu điều kiện kích hoạt và các khoá-giá trị tổng hợp trên nền tảng web và ứng dụng, thì công nghệ quảng cáo có thể phân biệt giữa lượt chuyển đổi trên web và trong ứng dụng:

• Đối với các báo cáo cấp sự kiện, chúng tôi sẽ hỗ trợ một trường đích chỉ định liệu trình kích hoạt xảy ra trên web (đích đến là một eTLD+1) hay ứng dụng (đích đến là tên gói ứng dụng)
• Đối với các báo cáo tổng hợp, đích đến sẽ được gửi ở dạng văn bản thô.

Ý nghĩa của việc đo lường giữa các trang web

Các ứng dụng chọn thời điểm chuyển đăng ký sang API Báo cáo phân bổ. Có một số điểm cần cân nhắc ở đây:

• API Báo cáo phân bổ có sẵn trên thiết bị đó không? Chúng tôi sẽ hiển thị một tín hiệu mới trên các ứng dụng sẽ trả về thông tin liệu API Báo cáo phân bổ có hoạt động trên thiết bị đó hay không. Vui lòng xem phần các thay đổi của ứng dụng để biết thêm thông tin chi tiết về cách ứng dụng chuyển đăng ký tới API Báo cáo phân bổ.
• Bạn nên truyền phần nào của các nguồn phân bổ và trình kích hoạt tới API? Đây sẽ là quyết định của từng ứng dụng hoặc công nghệ quảng cáo nếu ứng dụng cho phép lựa chọn. Nếu ứng dụng có giải pháp đo lường riêng, ứng dụng có thể muốn xem xét sử dụng giải pháp đó. Cuối cùng, việc truyền mọi nguồn và lượt đăng ký trình kích hoạt sang API Báo cáo phân bổ của Android (nếu có) sẽ cho phép phân bổ chính xác nhất trên các ứng dụng và web.

Ví dụ sau đây cho thấy cách các ứng dụng trình duyệt có thể hoạt động với API Báo cáo phân bổ để cung cấp kết quả đo lường chính xác khi người dùng nhấp vào quảng cáo, trong cả ứng dụng trình duyệt và ứng dụng không phải trình duyệt:

• Vào ngày đầu tiên, người dùng nhấp vào quảng cáo trong ứng dụng trình duyệt.
  • Ứng dụng trình duyệt có thể chọn sử dụng giải pháp đo lường riêng, hoặc chuyển quy trình đăng ký lượt nhấp quảng cáo trên web đến API báo cáo phân bổ.
• Vào ngày thứ 2, người dùng nhấp vào quảng cáo trong một ứng dụng không phải trình duyệt.
  • Lượt nhấp được đăng ký dưới dạng nguồn phân bổ bằng API. Ứng dụng trình duyệt không hiển thị lượt nhấp này vì sự kiện đã xảy ra trong một ứng dụng khác.
• Vào ngày thứ 3, người dùng chuyển đổi trong ứng dụng trình duyệt.
  • Nếu ứng dụng trình duyệt đăng ký cả lượt nhấp lẫn lượt chuyển đổi bằng cách sử dụng giải pháp đo lường riêng, đồng thời chuyển thông tin đó đến Attribution Reporting API, thì rất khó để công nghệ quảng cáo có thể loại bỏ báo cáo chuyển đổi trùng lặp trên các giải pháp đo lường. Ngoài ra, một công nghệ quảng cáo có thể sử dụng cả giới hạn tỷ lệ của ứng dụng trình duyệt lẫn giới hạn tỷ lệ của Attribution Reporting API. Do đó, ứng dụng nên truyền mọi sự kiện quảng cáo và lượt chuyển đổi để được đăng ký trên API, khi API có sẵn.

Đăng ký nguồn phân bổ và điều kiện kích hoạt từ WebView

Trong trường hợp ứng dụng đang dùng WebView để hiện nội dung web thay vì hiện quảng cáo Android, ứng dụng có thể đăng ký tham gia danh sách cho phép dành cho registerWebSource() và cung cấp gốc cấp cao nhất của trang web để được liên kết với nguồn phân bổ thay vì với tên gói ứng dụng.

Tương tự như các trình duyệt, WebView hỗ trợ registerWebTrigger() cho các lượt đăng ký điều kiện kích hoạt, điều này liên kết điều kiện kích hoạt với gốc cấp cao nhất. WebView không hỗ trợ đăng ký điều kiện kích hoạt ứng dụng; hãy liên hệ nếu bạn có trường hợp sử dụng không được hỗ trợ. Để xem danh sách đầy đủ các trường hợp sử dụng kết hợp mà WebView hỗ trợ, hãy tham khảo bài viết Nguồn phân bổ và đăng ký điều kiện kích hoạt từ WebView.

Khác với các trình duyệt, WebView chỉ hỗ trợ đăng ký với hệ điều hành trong tiêu đề Attribution-Reporting-Eligible nếu dùng được Attribution Reporting API của Android. Nếu không dùng được Attribution Reporting API của Android, thì WebView sẽ không đặt tiêu đề Attribution-Reporting-Eligible và không thực hiện lượt đăng ký nào.

Cách đăng ký nguồn phân bổ / điều kiện kích hoạt bằng hệ điều hành:

• Công nghệ quảng cáo phải phản hồi các lượt đăng ký nguồn bằng cách sử dụng tiêu đề Attribution-Reporting-Register-OS-Source. Tiêu đề này sẽ bắt đầu một lệnh gọi API phụ từ WebView đến registerSource() hoặc registerWebSource().
• Công nghệ quảng cáo cũng có thể phản hồi các lượt đăng ký điều kiện kích hoạt bằng cách sử dụng tiêu đề Attribution-Reporting-Register-OS-Trigger. Tiêu đề này sẽ bắt đầu lệnh gọi API phụ từ WebView đến registerWebTrigger() hoặc registerTrigger().

Xin lưu ý rằng nếu phản hồi không bao gồm các tiêu đề trước đó hoặc bao gồm cả tiêu đề Attribution-Reporting-Register-Source/Attribution-Reporting-Register-Trigger dù web không được hỗ trợ, thì toàn bộ quá trình đăng ký sẽ không thành công.

Để biết chi tiết về việc WebView sẽ dùng registerSource() hay registerWebSource() và registerTrigger() hay registerWebTrigger() (cũng như cách thay đổi hành vi này), hãy tham khảo phần Đăng ký nguồn phân bổ và điều kiện kích hoạt từ WebView.

Báo cáo gỡ lỗi chuyển đổi

Attribution Reporting API hỗ trợ một tính năng không bắt buộc gọi là báo cáo gỡ lỗi chuyển đổi. Chức năng này cho phép các công nghệ quảng cáo tìm hiểu thêm thông tin về báo cáo phân bổ khi có mã nhận dạng cho quảng cáo. Có hai loại báo cáo gỡ lỗi: phân bổ thành công và chi tiết. Các báo cáo này được hỗ trợ cho mô hình phân bổ trên nhiều ứng dụng và web. Cả hai loại báo cáo đều chứa cùng một thông tin. Sự khác biệt duy nhất là các quyền đưa ra khi gửi báo cáo gỡ lỗi.

Đối với mô hình phân bổ giữa các trang web xảy ra trong một ứng dụng (chẳng hạn như trong cùng một ứng dụng trình duyệt), báo cáo phân bổ thành công và báo cáo chi tiết chỉ được cung cấp khi có cookie của bên thứ ba và không phụ thuộc vào việc có mã nhận dạng cho quảng cáo hay không.

Đối với mô hình phân bổ nhiều ứng dụng từ ứng dụng đến web, từ web đến ứng dụng và giữa các trang web, báo cáo phân bổ thành công và báo cáo chi tiết được cung cấp nếu có mã nhận dạng cho quảng cáo ở phía ứng dụng và công nghệ quảng cáo có thể chuyển cùng một mã nhận dạng cho quảng cáo (chính xác) ở phía web.

Trong ví dụ sau về mô hình từ ứng dụng đến web, nguồn xảy ra trong ứng dụng của nhà xuất bản, nhưng điều kiện kích hoạt xảy ra trên trang web của nhà quảng cáo bên trong ứng dụng trình duyệt.

Để bật báo cáo gỡ lỗi phân bổ thành công cho mô hình từ ứng dụng đến web, bạn phải đáp ứng các điều kiện sau:

• Người dùng phải chọn sử dụng tuỳ chọn cá nhân hoá bằng mã nhận dạng cho quảng cáo
• Ứng dụng của nhà xuất bản phải khai báo quyền sử dụng mã nhận dạng cho quảng cáo
• Công nghệ quảng cáo phải chuyển giá trị mã nhận dạng cho quảng cáo trong quy trình đăng ký điều kiện kích hoạt (từ ngữ cảnh web)

Cách bật tính năng báo cáo gỡ lỗi chi tiết cho mô hình từ ứng dụng đến web:

• Báo cáo chi tiết nguồn chỉ phụ thuộc vào quyền của phía nhà xuất bản. Để gửi báo cáo chi tiết về nguồn, người dùng phải chọn sử dụng tuỳ chọn cá nhân hoá bằng mã nhận dạng cho quảng cáo và ứng dụng của nhà xuất bản phải khai báo quyền sử dụng mã nhận dạng cho quảng cáo.
• Báo cáo chi tiết về điều kiện kích hoạt chỉ phụ thuộc vào các quyền của phía điều kiện kích hoạt (trong ví dụ này là web). Bạn phải có cookie của bên thứ ba trong trình duyệt để gửi báo cáo chi tiết.
• Đối với các báo cáo chi tiết về điều kiện kích hoạt có thể bao gồm source_debug_key, source_debug_key sẽ được đưa vào nếu ứng dụng của nhà xuất bản có mã nhận dạng cho quảng cáo.

Lưu ý rằng trong mọi trường hợp, công nghệ quảng cáo vẫn cần phải chọn nhận các báo cáo gỡ lỗi chi tiết thông qua trường từ điển debug_reporting trong các tiêu đề nguồn và đăng ký điều kiện kích hoạt.

Các thay đổi đối với ứng dụng

Chúng tôi sẽ hỗ trợ phân bổ trên các nền tảng ứng dụng và web, bằng cách cho phép ứng dụng chuyển lượt đăng ký các nguồn phân bổ trên web cũng như trình kích hoạt web đến API Báo cáo phân bổ trên Android, thông qua một nhóm các lệnh gọi API ngữ cảnh web mới.

Sau khi hoàn tất các bước đăng ký trong phần sau đây, nguồn phân bổ và trình kích hoạt web cũng như ứng dụng sẽ được lưu trữ trên thiết bị, đồng thời Attribution Reporting API có thể thực hiện mô hình phân bổ ưu tiên nguồn, ở đây là lượt nhấn cuối cùng trên các nền tảng ứng dụng và web.

Xem Hộp cát về quyền riêng tư cho đề xuất của web để biết ví dụ về cách các trình duyệt có thể tích hợp với Attribution Reporting API trên Android nhằm cho phép đo lường trên nhiều ứng dụng và web. Trong đề xuất, trình duyệt sẽ thêm các tiêu đề sau đây của yêu cầu:

• Attribution-Reporting-Eligible cho biết liệu có chế độ hỗ trợ cấp hệ điều hành cho mô hình phân bổ hay không. Trong trường hợp này, tiêu đề cho biết liệu Attribution Reporting API của Android có dùng được hay không.
• Nếu có, các công nghệ quảng cáo có thể phản hồi bằng cách sử dụng Attribution-Reporting-Register-OS-Source để bắt đầu lệnh gọi API phụ từ ứng dụng trình duyệt đến registerWebSource().
• Công nghệ quảng cáo cũng có thể phản hồi các lượt đăng ký kích hoạt bằng cách sử dụng tiêu đề Attribution-Reporting-Register-OS-Trigger. Tiêu đề này sẽ bắt đầu lệnh gọi API phụ từ ứng dụng trình duyệt đến registerWebTrigger().

Đăng ký nguồn phân bổ

Khi đăng ký nguồn phân bổ, các ứng dụng có thể gọi registerWebSource() với các tham số sau:

• URI nguồn phân bổ: Nền tảng đưa ra yêu cầu cho từng URI trong danh sách này để tìm nạp siêu dữ liệu được liên kết với nguồn phân bổ.
  
  Mỗi URI phải đi kèm với một cờ Gỡ lỗi boolean để cho biết liệu các khoá gỡ lỗi do các công nghệ cung cấp có nên được đưa vào báo cáo hay không.
• Sự kiện đầu vào: Một đối tượng InputEvent (đối với sự kiện nhấp chuột) hoặc null (đối với sự kiện xem)
• Nguồn gốc: Nguồn gốc nơi nguồn xuất hiện (trang web của nhà xuất bản).
• Đích đến của hệ điều hành: Tên gói ứng dụng nơi diễn ra sự kiện kích hoạt.
• Đích đến trên web: Một eTLD+1 nơi diễn ra sự kiện kích hoạt.
• Đích đến đã xác minh: Hệ điều hành hoặc ý định URI đích của web được dùng để điều hướng khi người dùng nhấp chuột.

Khi API gửi yêu cầu đến URI nguồn phân bổ, công nghệ quảng cáo sẽ phản hồi thông qua siêu dữ liệu nguồn phân bổ trong tiêu đề HTTP Attribution-Reporting-Register-Source. Tiêu đề này sử dụng các trường giống như quy trình đăng ký nguồn phân bổ ứng dụng với ứng dụng, với một số thay đổi bên dưới:

• API xác thực các đích đến do công nghệ quảng cáo chỉ định với các đích đến do ứng dụng chỉ định. Nếu các đích đến khác nhau, API sẽ huỷ việc đăng ký nguồn phân bổ.
  
  Ứng dụng được dự kiến sẽ xác thực các đích đến trang web trước khi gọi API ngữ cảnh web. Đối với các lượt nhấp, ứng dụng phải kiểm tra để đảm bảo đích đến được chỉ định khớp với đích mà người dùng đang di chuyển.
• API bỏ qua mọi URI chuyển hướng đã cung cấp trong Attribution-Reporting-Redirects. Các ứng dụng phải tự theo dõi lệnh chuyển hướng, đồng thời gọi registerWebSource() cho mỗi lệnh chuyển hướng để có thể áp dụng các chính sách quyền truy cập riêng khi cần.

Các ứng dụng phải tham gia danh sách cho phép để gọi được registerWebSource(). Hoàn tất biểu mẫu này để tham gia danh sách cho phép. Mục đích của danh sách cho phép là giảm thiểu các cân nhắc về quyền riêng tư liên quan đến việc thiết lập niềm tin cho ngữ cảnh web.

Đăng ký trình kích hoạt (lượt chuyển đổi)

Khi đăng ký trình kích hoạt, các ứng dụng có thể gọi registerWebTrigger() với các tham số sau:

• URI trình kích hoạt: Nền tảng đưa ra yêu cầu cho từng URI trong danh sách này để tìm nạp siêu dữ liệu được liên kết với trình kích hoạt
• Nguồn gốc đích: Nguồn gốc nơi xuất hiện điều kiện kích hoạt (trang web của nhà quảng cáo)

Đăng ký nguồn phân bổ và điều kiện kích hoạt từ WebView

Theo mặc định, WebView sẽ dùng registerSource() và registerWebTrigger(). Phương thức này liên kết các nguồn với ứng dụng và các điều kiện kích hoạt với gốc cấp cao nhất của WebView khi điều kiện kích hoạt xảy ra.

Nếu một ứng dụng đòi hỏi hành vi khác (chẳng hạn như ứng dụng lưu trữ nội dung web trên WebView), ứng dụng đó sẽ phải dùng phương thức setAttributionRegistrationBehavior cho lớp androidx.webkit.WebViewSettingsCompat. Phương thức này sẽ chỉ định liệu WebView cần gọi registerWebSource() hay registerSource() và registerWebTrigger() hay registerTrigger().

Có các lựa chọn như sau cho setAttributionRegistrationBehavior:

Giá trị	Nội dung mô tả	Trường hợp sử dụng mẫu
APP_SOURCE_AND_WEB_TRIGGER (mặc định)	Cho phép ứng dụng đăng ký nguồn ứng dụng (những nguồn có liên kết với tên gói ứng dụng) và điều kiện kích hoạt web (những điều kiện kích hoạt có liên kết với eTLD+1) qua WebView.	Ứng dụng dùng WebView để phân phát quảng cáo thay vì bật tính năng duyệt web
WEB_SOURCE_AND_WEB_TRIGGER	Cho phép ứng dụng đăng ký nguồn web và điều kiện kích hoạt web qua WebView. Lưu ý: Nếu dùng tuỳ chọn này, các ứng dụng sẽ cần phải đăng ký tham gia danh sách cho phép thì mới dùng được registerWebSource().	Ứng dụng trình duyệt dựa trên WebView, trong đó cả lượt hiển thị quảng cáo và lượt chuyển đổi đều có thể xảy ra ở các trang web trong WebView.
APP_SOURCE_AND_APP_TRIGGER	Cho phép ứng dụng đăng ký nguồn ứng dụng và điều kiện kích hoạt ứng dụng qua WebView.	Ứng dụng dựa trên WebView nơi lượt hiển thị quảng cáo và lượt chuyển đổi phải luôn được liên kết với ứng dụng thay vì với eTLD+1 của WebView.
ĐÃ TẮT	Tắt đăng ký nguồn và điều kiện kích hoạt qua WebView. Xin lưu ý rằng lệnh gọi mạng ban đầu đến Nguồn phân bổ hoặc URI có điều kiện kích hoạt vẫn có thể xảy ra, nhưng mọi phản hồi đều sẽ bị loại bỏ và sẽ không có phản hồi nào được lưu trữ trên thiết bị.

Những điều cần cân nhắc về quyền riêng tư và bảo mật

Phần này thảo luận về những điểm cần cân nhắc về quyền riêng tư và bảo mật đối với các ứng dụng sử dụng API Báo cáo phân bổ.

Tác động về cơ chế bảo đảm quyền riêng tư được áp dụng cho các báo cáo

Như đã đề cập trong đề xuất thiết kế chính, API sẽ áp dụng giới hạn tỷ lệ bảo vệ quyền riêng tư cho các báo cáo. Một số giới hạn được phân vùng trên các ứng dụng nguồn và đích. Khi một trình kích hoạt hoặc nguồn phân bổ web được đăng ký, giới hạn tỷ lệ được phân vùng theo nguồn hoặc trang web đích thay vì ứng dụng.

Nếu ứng dụng duy trì giới hạn tỷ lệ riêng biệt, thì đối thủ cạnh tranh có thể sử dụng giới hạn tỷ lệ dành riêng cho ứng dụng ngoài các giới hạn tỷ lệ của API. Để giảm thiểu điều này, các ứng dụng phải đảm bảo một nguồn phân bổ nhất định không được đăng ký trên cả giải pháp đo lường của ứng dụng lẫn Attribution Reporting API của Android.

Thiết lập niềm tin cho ngữ cảnh web

Trong lệnh gọi API ngữ cảnh web, API đặt niềm tin vào ứng dụng trong việc phát hiện và chỉ định nguồn và nguồn gốc của đích. Điều này dẫn đến một số cân nhắc tiềm ẩn về quyền riêng tư và bảo mật:

• Đối thủ có thể tuyên bố đang lưu trữ các trang web mà họ sở hữu nhằm tìm cách bỏ qua giới hạn tỷ lệ về lượng thông tin mà bất kỳ nguồn nào cũng có thể chuyển.
• Nhiều đối thủ có thể liên kết với nhau để đăng ký các nguồn phân bổ riêng biệt, xác nhận quyền sở hữu trên cùng một trang web nguồn. Điều này có thể khiến trang web nguồn đạt đến giới hạn tỷ lệ của nền tảng công nghệ quảng cáo, ngăn trang web nguồn thực tế đăng ký các nguồn phân bổ hợp pháp.

Để giảm thiểu điều này, chúng tôi sẽ giới hạn các trình duyệt hoặc ứng dụng có thể gọi registerWebSource() đến các trình duyệt hoặc ứng dụng chứng thực trang web nguồn được sử dụng trong quá trình đăng ký đại diện cho trang web thực tế mà người dùng đang nhìn thấy. Điền vào biểu mẫu đăng ký Báo cáo phân bổ web-to-app để tham gia danh sách cho phép gọi registerWebSource().

Bất kỳ ứng dụng nào cũng có thể gọi registerWebTrigger() vì các cân nhắc về quyền riêng tư và bảo mật ở phía trình kích hoạt sẽ không thể áp dụng nếu không có liên kết từ phía nguồn.

Quyền kiểm soát của người dùng

Các ứng dụng sẽ tiếp tục hỗ trợ chính sách về quyền kiểm soát hoặc quyền truy cập của người dùng, miễn là bạn có thể xác định các chính sách này tại thời điểm đăng ký. Chẳng hạn nếu ứng dụng cho phép bất kỳ quyền riêng biệt ở cấp trang web hoặc cấp người dùng nào, thì ứng dụng sẽ đánh giá các quyền đó và xác định xem sẽ gọi API ngữ cảnh web hay không.

Ngoài ra, chúng tôi sẽ hỗ trợ một lệnh gọi API mới từ ứng dụng giúp xoá mọi nguồn phân bổ, trình kích hoạt và báo cáo đang chờ xử lý đã lưu trữ cho ứng dụng đó trên thiết bị. Chẳng hạn nếu ứng dụng cho phép người dùng xoá nhật ký duyệt web, thì ứng dụng nên gọi API để xoá các nguồn phân bổ, trình kích hoạt và báo cáo đang chờ xử lý được lưu trữ cho ứng dụng đó trên thiết bị của người dùng.

Câu hỏi mở và những điều cần cân nhắc sau này

Khả năng tương tác giữa ứng dụng với web cho API báo cáo phân bổ đang trong quá trình hoàn thiện. Chúng tôi mong nhận được phản hồi của cộng đồng về một số ý tưởng:

1. Trong thiết bị được hỗ trợ Hộp cát về quyền riêng tư trên Android, bạn sẽ dùng các giải pháp đo lường trình duyệt bằng API Báo cáo phân bổ của Android như thế nào? Bạn có muốn chuyển mọi thứ sang Android không?
2. Việc có thể nhận 2 ping cho mỗi nguồn phân bổ và trình kích hoạt có gì đáng ngại không? Trong đó có một ping từ trình duyệt hoặc ứng dụng và một ping từ Attribution Reporting API.
3. Chúng tôi có thể làm gì để giúp bạn gỡ lỗi trên các API khác nhau dễ dàng hơn?
4. Đề xuất không bao gồm việc xác thực các đích đến của ứng dụng và web được liên kết. Trong tương lai, chúng tôi có thể xác thực các đích đến này bằng cách kiểm tra các liên kết sử dụng Đường liên kết đến tài sản kỹ thuật số. Liệu việc này có gây cản trở cho bất kỳ trường hợp sử dụng nào của bạn không? Việc sử dụng Đường liên kết đến tài sản kỹ thuật số để xác thực thông tin này có hợp lý không?
5. Khi đăng ký nguồn phân bổ, bạn phải chỉ định một đích đến. Trong trường hợp từ web đến ứng dụng, bạn có thể muốn chỉ định một đường liên kết đến ứng dụng. Bạn sử dụng định dạng nào để chỉ định đường liên kết đến ứng dụng này?
6. Khi đăng ký nguồn phân bổ từ ứng dụng đến web, sự kiện nguồn đó sẽ cần được đăng ký từ ứng dụng bằng Attribution Reporting API của Android. Ví dụ: nếu người dùng nhấp vào một quảng cáo và lượt nhấp được mở trong một trình duyệt hoặc thẻ tuỳ chỉnh của trình duyệt, thì lượt nhấp đó (sự kiện nguồn) phải được đăng ký từ ứng dụng thay vì trong ngữ cảnh của trình duyệt. Hãy liên hệ nếu bạn có thắc mắc nào liên quan đến vấn đề này, hoặc nếu có trường hợp sử dụng khác không thuộc danh mục được đề cập trong các quy trình được hỗ trợ để mô tả về vấn đề.

Đề xuất cho bạn

• Lưu ý: văn bản có đường liên kết sẽ hiện khi JavaScript tắt
• Attribution Reporting
• Hướng dẫn dành cho nhà phát triển về Attribution Reporting API
• Ghi chú phát hành