Báo cáo phân bổ

Lưu ý: Tài liệu này đề cập đến các đề xuất thiết kế hiện tại của Hộp cát về quyền riêng tư trên Android và tài liệu này còn tiếp tục thay đổi. Chúng tôi mong nhận được ý kiến phản hồi và nhận xét của bạn để có thể tiếp tục cải thiện.

Gửi ý kiến phản hồi

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

• Cập nhật danh sách các thay đổi sắp tới và các vấn đề đã biết
• Ra mắt cấu hình cấp sự kiện linh hoạt và thu gọn làm cầu nối tới cấu hình cấp sự kiện linh hoạt và đầy đủ
• Kể từ tháng 9 năm 2023, registerWebSource, registerWebTrigger, registerAppSource và registerAppTrigger phải sử dụng chuỗi cho các trường yêu cầu một giá trị số (chẳng hạn như priority, source_event_id, debug_key, trigger_data, deduplication_key, v.v.)
• Trong Quý 4 năm 2023, dịch vụ hỗ trợ Google Cloud trong Attribution Reporting API của Android sẽ được thêm vào để tạo báo cáo tóm tắt bằng Dịch vụ tổng hợp trên Google Cloud. Thời gian cụ thể hơn sẽ được đề cập tại đây. Xem hướng dẫn triển khai để biết thêm thông tin về cách thiết lập Dịch vụ tổng hợp trên Google Cloud.
• Giới hạn mới về số lượng yêu cầu bảo đảm quyền riêng tư cho số lượng các điểm đến duy nhất.
• Cập nhật chức năng cho các bộ lọc điều kiện kích hoạt của giai đoạn xem lại. Đây là các bộ lọc sẽ ra mắt vào Quý 1 năm 2024.

Tổng quan

Ngày nay, các giải pháp phân bổ và đo lường trên thiết bị di động thường sử dụng giá trị nhận dạng giữa nhiều bên, chẳng hạn như Mã nhận dạng cho quảng cáo. API Báo cáo phân bổ được thiết kế nhằm tăng cường quyền riêng tư cho người dùng thông qua việc loại bỏ sự phụ thuộc vào giá trị nhận dạng người dùng giữa nhiều bên, cũng như để hỗ trợ các trường hợp sử dụng chính nhằm phân bổ và đo lường lượt chuyển đổi trên các ứng dụng và web.

API này có các cơ chế cấu trúc sau đây nhằm cung cấp một khung để cải thiện quyền riêng tư (các phần sau của trang này sẽ mô tả chi tiết hơn):

• Giới hạn số lượng bit có sẵn cho báo cáo cấp sự kiện
• Chỉ bật dữ liệu chuyển đổi có độ trung thực cao hơn trong báo cáo tổng hợp
• Giới thiệu về giới hạn số lượng yêu cầu cho các điều kiện kích hoạt sẵn có (lượt chuyển đổi) và số công nghệ quảng cáo có thể liên kết với một nguồn phân bổ
• Kết hợp nhiều kỹ thuật thêm nhiễu

Các cơ chế trước đây giới hạn khả năng liên kết danh tính người dùng trên 2 ứng dụng hoặc miền khác nhau.

API Báo cáo phân bổ hỗ trợ các trường hợp sử dụng sau đây:

• Báo cáo lượt chuyển đổi: Giúp nhà quảng cáo đo lường hiệu quả chiến dịch bằng cách cho họ thấy số lượt chuyển đổi (điều kiện kích hoạt) và giá trị lượt chuyển đổi (điều kiện kích hoạt) trên các phương diện khác nhau, chẳng hạn như chiến dịch, nhóm quảng cáo và mẫu quảng cáo.
• Tối ưu hoá: Cung cấp các báo cáo cấp sự kiện hỗ trợ tối ưu hoá mức chi tiêu quảng cáo, bằng cách cung cấp dữ liệu phân bổ trên mỗi lượt hiển thị có thể dùng để đào tạo mô hình ML.
• Phát hiện hoạt động không hợp lệ: Cung cấp báo cáo có thể dùng trong tính năng phân tích và phát hiện lưu lượng truy cập không hợp lệ cũng như gian lận trong quảng cáo.

Nhìn chung, API Báo cáo phân bổ hoạt động như sau (các phần sau trong tài liệu này sẽ mô tả chi tiết hơn):

1. Công nghệ quảng cáo hoàn tất quy trình đăng ký để sử dụng API Báo cáo phân bổ.
2. Công nghệ quảng cáo đăng ký các nguồn phân bổ – lượt nhấp vào quảng cáo hoặc lượt xem – bằng API Báo cáo phân bổ.
3. Công nghệ quảng cáo đăng ký điều kiện kích hoạt – lượt chuyển đổi của người dùng trên ứng dụng hoặc trang web của nhà quảng cáo – bằng API Báo cáo phân bổ.
4. Attribution Reporting API so khớp điều kiện kích hoạt với nguồn phân bổ – phân bổ lượt chuyển đổi – và một hoặc nhiều điều kiện kích hoạt được gửi ra khỏi thiết bị thông qua các báo cáo cấp sự kiện và tổng hợp cho công nghệ quảng cáo.

Lưu ý: Để biết thêm thông tin về cách triển khai thiết kế này cho trường hợp sử dụng phân bổ từ ứng dụng đến ứng dụng, hãy đọc phần hướng dẫn về phân bổ trên nhiều mạng trong Hướng dẫn dành cho nhà phát triển về API Attribution Reporting. Để tìm hiểu cách triển khai trường hợp sử dụng phân bổ từ ứng dụng đến web hoặc từ web đến ứng dụng, vui lòng đọc bài viết Đề xuất về thiết kế dữ liệu đo lường giữa nhiều ứng dụng và trang web.

Truy cập vào API Attribution Reporting

Các nền tảng công nghệ quảng cáo cần đăng ký để truy cập vào API Báo cáo phân bổ. 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.

Đăng ký một nguồn phân bổ (lượt nhấp hoặc lượt xem)

API Báo cáo phân bổ đề cập đến lượt nhấp vào quảng cáo và lượt xem quảng cáo ở dạng nguồn phân bổ. Để đăng ký một lượt nhấp vào quảng cáo hoặc lượt xem quảng cáo, hãy gọi registerSource(). API này yêu cầu các tham số sau đây:

• URI nguồn phân bổ: Nền tảng đưa ra yêu cầu cho URI này để tìm nạp siêu dữ liệu liên kết với nguồn phân bổ.
• 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).

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 mới Attribution-Reporting-Register-Source, với các trường sau đây:

• Mã nhận dạng sự kiện nguồn: Giá trị này biểu thị dữ liệu cấp sự kiện liên kết với nguồn phân bổ này (lượt xem hoặc lượt nhấp vào quảng cáo). Phải là số nguyên 64 bit đã ký có định dạng chuỗi.
• Đích: Một nguồn gốc có eTLD+1 hoặc tên gói ứng dụng trong đó xảy ra sự kiện kích hoạt.
• Thời gian hết hạn (không bắt buộc): Thời gian hết hạn (tính bằng giây) là thời gian mà nguồn phải được xoá khỏi thiết bị. Giá trị mặc định là 30 ngày, với giá trị nhỏ nhất là 1 ngày và giá trị lớn nhất là 30 ngày. Giá trị này được làm tròn đến ngày gần nhất. Có thể định dạng thành số nguyên hoặc chuỗi 64 bit chưa ký.
• Khoảng thời gian báo cáo sự kiện (không bắt buộc): Thời lượng tính bằng giây sau khi đăng ký nguồn mà bạn có thể tạo báo cáo sự kiện cho nguồn này. Nếu khoảng thời gian báo cáo sự kiện đã qua nhưng chưa hết hạn, thì bạn vẫn có thể so khớp điều kiện kích hoạt với một nguồn, nhưng không gửi được báo cáo sự kiện cho điều kiện kích hoạt đó. Không được vượt quá Thời gian hết hạn. Có thể định dạng thành số nguyên hoặc chuỗi 64 bit chưa ký.
• Khoảng thời gian báo cáo tổng hợp (không bắt buộc): Thời lượng tính bằng giây sau quá trình đăng ký nguồn mà bạn có thể tạo báo cáo tổng hợp cho nguồn này. Không được vượt quá Thời gian hết hạn. Có thể định dạng thành số nguyên hoặc chuỗi 64 bit chưa ký.
• Mức ưu tiên nguồn (không bắt buộc): Dùng để chọn nguồn phân bổ mà một điều kiện kích hoạt nhất định sẽ liên kết, trong trường hợp có nhiều nguồn phân bổ có thể liên kết với điều kiện kích hoạt này. Phải là số nguyên 64 bit đã ký có định dạng chuỗi.
  
  Khi nhận được một điều kiện kích hoạt, API sẽ tìm nguồn phân bổ phù hợp có giá trị mức ưu tiên nguồn cao nhất và tạo một báo cáo. Mỗi nền tảng công nghệ quảng cáo có thể xác định chiến lược ưu tiên riêng của nền tảng đó. Để biết thêm thông tin về cách mức độ ưu tiên tác động đến hoạt động phân bổ, vui lòng xem mục ví dụ về mức độ ưu tiên.
  
  Giá trị càng cao thì mức độ ưu tiên càng cao.
• Thời lượng phân bổ sự kiện cài đặt và sự kiện sau cài đặt (không bắt buộc): Dùng để xác định tính năng phân bổ cho sự kiện sau cài đặt, như mô tả ở phần sau của trang này.
• Lọc dữ liệu (không bắt buộc): Dùng để lọc một số điều kiện kích hoạt có chọn lọc, bỏ qua những điều kiện này một cách hiệu quả. Để biết thêm thông tin, vui lòng xem phần các bộ lọc điều kiện kích hoạt trên trang này.
• Khoá tổng hợp (không bắt buộc): Chỉ định phân đoạn sẽ được dùng cho báo cáo tổng hợp.

Phản hồi của siêu dữ liệu nguồn phân bổ có thể bao gồm dữ liệu bổ sung trong tiêu đề Chuyển hướng Báo cáo phân bổ (không bắt buộc). Dữ liệu chứa URL chuyển hướng cho phép nhiều công nghệ quảng cáo đăng ký một yêu cầu.

Tài liệu hướng dẫn của nhà phát triển có các ví dụ về cách chấp nhận lượt đăng ký nguồn.

Các bước sau đây minh hoạ một quy trình mẫu:

1. SDK công nghệ quảng cáo gọi API để bắt đầu đăng ký nguồn phân bổ, chỉ định URI cho API gọi:

   registerSource(
       Uri.parse("https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA"),
       myClickEvent);
   

2. API gửi yêu cầu tới https://adtech.example/attribution_source?AD_TECH_PROVIDED_METADATA, sử dụng một trong những tiêu đề sau:

   <!-- For click events -->
   Attribution-Reporting-Source-Info: navigation
   
   <!-- For view events -->
   Attribution-Reporting-Source-Info: event
   

3. Máy chủ HTTPS của công nghệ quảng cáo này phản hồi bằng các tiêu đề chứa thông tin sau:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "234",
       "expiry": "60000",
       "priority": "5"
   }
   Attribution-Reporting-Redirect:
   https://adtechpartner1.example?their_ad_click_id=567
   Attribution-Reporting-Redirect:
   https://adtechpartner2.example?their_ad_click_id=890
   

4. API gửi yêu cầu cho từng URL được chỉ định trong Attribution-Reporting-Redirect. Trong ví dụ này, 2 URL đối tác công nghệ quảng cáo được xác định, vì vậy, API gửi một yêu cầu đến https://adtechpartner1.example?their_ad_click_id=567 và một yêu cầu khác đến https://adtechpartner2.example?their_ad_click_id=890.

5. Máy chủ HTTPS của công nghệ quảng cáo này phản hồi bằng các tiêu đề chứa thông tin sau:

   Attribution-Reporting-Register-Source: {
       "destination": "android-app://com.advertiser.example",
       "source_event_id": "789",
       "expiry": "120000",
       "priority": "2"
   }
   

   Lưu ý: Phản hồi của công nghệ quảng cáo có thể chỉ định nhiều siêu dữ liệu trong tiêu đề Attribution-Reporting-Register-Source.

3 nguồn phân bổ điều hướng (lượt nhấp) được đăng ký dựa trên yêu cầu nêu trong các bước trước.

Đăng ký một nguồn phân bổ qua WebView

WebView hỗ trợ trường hợp sử dụng trong đó ứng dụng đang hiển thị một quảng cáo trong WebView. Để xử lý trường hợp này, WebView trực tiếp gọi registerSource() dưới dạng một yêu cầu ở chế độ nền. Lệnh gọi này liên kết nguồn phân bổ với ứng dụng thay vì với gốc cấp cao nhất. Quy trình đăng ký nguồn từ nội dung trên web được nhúng trong ngữ cảnh trình duyệt cũng được hỗ trợ; cả lệnh gọi API và ứng dụng đều cần điều chỉnh chế độ cài đặt để thực hiện việc này. Xem phần Đăng ký nguồn phân bổ và điều kiện kích hoạt qua WebView để nắm được hướng dẫn về lệnh gọi API, cũng như xem phần Nguồn phân bổ và quy trình đăng ký điều kiện kích hoạt qua WebView để biết hướng dẫn dành cho ứng dụng.

Vì các công nghệ quảng cáo dùng mã chung trên Web và WebView, nên WebView sẽ tuân theo các lượt chuyển hướng HTTP 302 và chuyển các lượt đăng ký hợp lệ sang nền tảng. Chúng tôi không có kế hoạch hỗ trợ tiêu đề Attribution-Reporting-Redirect cho trường hợp này, nhưng bạn hãy liên hệ nếu có trường hợp sử dụng bị ảnh hưởng.

Đăng ký một điều kiện kích hoạt (lượt chuyển đổi)

Các nền tảng công nghệ quảng cáo có thể đăng ký điều kiện kích hoạt — lượt chuyển đổi chẳng hạn như lượt cài đặt hoặc sự kiện sau cài đặt — bằng phương thức registerTrigger().

Phương thức registerTrigger() yêu cầu thông số URI điều kiện kích hoạt. API đưa ra yêu cầu cho URI này để tìm nạp siêu dữ liệu liên kết với điều kiện kích hoạt.

API tuân theo các lệnh chuyển hướng. Phản hồi của máy chủ công nghệ quảng cáo phải bao gồm tiêu đề HTTP gọi là Attribution-Reporting-Register-Trigger, đại diện cho thông tin trên một hoặc nhiều điều kiện kích hoạt đã đăng ký. Nội dung của tiêu đề phải được mã hoá bằng định dạng JSON và bao gồm các trường sau đây:

• Dữ liệu điều kiện kích hoạt: Dữ liệu để xác định sự kiện kích hoạt (3 bit cho lượt nhấp, 1 bit cho lượt xem). Phải là số nguyên 64 bit đã ký có định dạng chuỗi.
• Mức ưu tiên của trình kích hoạt (không bắt buộc): Thể hiện mức ưu tiên của trình kích hoạt này so với các trình kích hoạt khác cho cùng một nguồn phân bổ. Phải là số nguyên 64 bit đã ký có định dạng chuỗi. Để biết thêm thông tin về cách mức độ ưu tiên tác động đến hoạt động báo cáo, vui lòng xem mục mức độ ưu tiên.
• Khoá loại bỏ trùng lặp (không bắt buộc): Dùng để xác định các trường hợp cùng một điều kiện kích hoạt được đăng ký nhiều lần bằng cùng một nền tảng công nghệ quảng cáo, cho cùng một nguồn phân bổ. Phải là số nguyên 64 bit đã ký có định dạng chuỗi.
• Khoá tổng hợp (không bắt buộc): Danh sách từ điển chỉ định các khoá tổng hợp và báo cáo tổng hợp nào có giá trị được tổng hợp.
• Giá trị tổng hợp (không bắt buộc): Danh sách số lượng giá trị đóng góp cho từng khoá.
• Bộ lọc (không bắt buộc): Dùng để lọc điều kiện kích hoạt hoặc dữ liệu điều kiện kích hoạt một cách có chọn lọc. Để biết thêm thông tin, vui lòng xem phần các bộ lọc điều kiện kích hoạt trên trang này.

Phản hồi của máy chủ công nghệ quảng cáo có thể bao gồm dữ liệu bổ sung trong tiêu đề Chuyển hướng Báo cáo phân bổ (không bắt buộc). Dữ liệu chứa URL chuyển hướng cho phép nhiều công nghệ quảng cáo đăng ký yêu cầu.

Nhiều công nghệ quảng cáo có thể đăng ký cùng một sự kiện cho điều kiện kích hoạt bằng lệnh chuyển hướng trong trường Attribution-Reporting-Redirect hoặc nhiều lệnh gọi đến phương thức registerTrigger(). Bạn nên sử dụng trường khoá loại bỏ trùng lặp để tránh đưa các điều kiện kích hoạt trùng lặp vào báo cáo trong trường hợp cùng một công nghệ quảng cáo cung cấp nhiều phản hồi cho cùng một sự kiện của điều kiện kích hoạt. Tìm hiểu thêm về cách thức và thời điểm sử dụng khoá loại bỏ trùng lặp.

Tài liệu hướng dẫn cho nhà phát triển có các ví dụ về cách chấp nhận đăng ký điều kiện kích hoạt.

Các bước sau đây minh hoạ một quy trình mẫu:

1. SDK công nghệ quảng cáo gọi API để bắt đầu đăng ký điều kiện kích hoạt bằng URI đã đăng ký trước. 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.

   registerTrigger(
       Uri.parse("https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA"));
   

2. API gửi yêu cầu đến https://adtech.example/attribution_trigger?AD_TECH_PROVIDED_METADATA.

3. Máy chủ HTTPS của công nghệ quảng cáo này phản hồi bằng các tiêu đề chứa thông tin sau:

   Attribution-Reporting-Register-Trigger: {
       "event_trigger_data": [{
       "trigger_data": "1122",
       // This returns 010 for click-through conversions (CTCs) and 0 for
       // view-through conversions (VTCs) in reports
       "priority": "3",
       "deduplication_key": "3344"
       }],
   }
   Attribution-Reporting-Redirect: https://adtechpartner.example?app_install=567
   

   Lưu ý: Chỉ công nghệ quảng cáo khởi tạo lệnh gọi API mới có thể chỉ định các đối tác trong Attribution-Reporting-Redirect.

4. API gửi yêu cầu cho từng URL được chỉ định trong Attribution-Reporting-Redirect. Trong ví dụ này, chỉ có một URL được chỉ định, do đó, API sẽ gửi yêu cầu đến https://adtechpartner.example?app_install=567.

5. Máy chủ HTTPS của công nghệ quảng cáo này phản hồi bằng các tiêu đề chứa thông tin sau:

   Attribution-Reporting-Register-Trigger: {
   "event_trigger_data":[{
     "trigger_data": "5566",
     "priority": "3",
     "deduplication_key": "3344"
   }]
   }
   

   2 điều kiện kích hoạt được đăng ký dựa trên yêu cầu ở những bước trước.

Khả năng phân bổ

Các phần sau giải thích cách API Báo cáo phân bổ so khớp điều kiện kích hoạt chuyển đổi với nguồn phân bổ.

Đã áp dụng thuật toán phân bổ ưu tiên nguồn

API Báo cáo phân bổ sử dụng thuật toán phân bổ ưu tiên nguồn để so khớp một điều kiện kích hoạt (lượt chuyển đổi) với một nguồn phân bổ.

Các thông số ưu tiên cung cấp phương thức để tuỳ chỉnh việc phân bổ điều kiện kích hoạt đến các nguồn:

• Bạn có thể phân bổ điều kiện kích hoạt cho một số sự kiện quảng cáo nhất định so với các sự kiện khác. Ví dụ: bạn có thể chọn tập trung nhiều hơn vào số lượt nhấp thay vì số lượt xem hoặc tập trung vào các sự kiện trong vài chiến dịch nhất định.
• Bạn có thể định cấu hình nguồn phân bổ và điều kiện kích hoạt để khi đạt đến giới hạn lượt truy cập, bạn có nhiều khả năng nhận được báo cáo quan trọng hơn cho mình. Ví dụ: bạn có thể đảm bảo các lượt chuyển đổi có thể đặt giá thầu hoặc lượt chuyển đổi có giá trị cao có nhiều khả năng xuất hiện trong các báo cáo này hơn.

Trong trường hợp nhiều công nghệ quảng cáo đăng ký một nguồn phân bổ, như mô tả ở phần sau của trang này, quy trình phân bổ diễn ra độc lập đối với từng công nghệ quảng cáo. Đối với từng công nghệ quảng cáo, nguồn phân bổ có mức ưu tiên cao nhất sẽ được phân bổ bằng sự kiện của điều kiện kích hoạt. Nếu có nhiều nguồn phân bổ có cùng mức ưu tiên, thì API sẽ chọn nguồn phân bổ được đăng ký gần đây nhất. Mọi nguồn phân bổ khác không được chọn sẽ bị loại bỏ và không còn đủ điều kiện để phân bổ điều kiện kích hoạt trong tương lai.

Bộ lọc điều kiện kích hoạt

Việc đăng ký nguồn và điều kiện kích hoạt sẽ cung cấp cả chức năng bổ sung không bắt buộc để thực hiện những việc sau đây:

• Lọc một số điều kiện kích hoạt có chọn lọc, bỏ qua những điều kiện này một cách hiệu quả.
• Chọn dữ liệu điều kiện kích hoạt cho báo cáo cấp sự kiện dựa trên dữ liệu nguồn.
• Chọn loại trừ một điều kiện kích hoạt khỏi các báo cáo cấp sự kiện.

Để chọn lọc điều kiện kích hoạt, công nghệ quảng cáo có thể chỉ định dữ liệu bộ lọc, bao gồm các khoá và giá trị trong quá trình đăng ký nguồn và điều kiện kích hoạt. Nếu cùng một khoá được chỉ định cho cả nguồn lẫn điều kiện kích hoạt, thì điều kiện kích hoạt sẽ bị bỏ qua nếu điểm giao nhau trống. Ví dụ: một nguồn có thể chỉ định "product": ["1234"], trong đó product là khoá lọc và 1234 là giá trị. Nếu bạn đặt bộ lọc của trình kích hoạt thành "product": ["1111"], thì trình kích hoạt sẽ bị bỏ qua. Nếu không có khoá bộ lọc điều kiện kích hoạt nào phù hợp với product, thì các bộ lọc sẽ bị bỏ qua.

Một tình huống khác trong đó các nền tảng công nghệ quảng cáo có thể muốn chọn lọc điều kiện kích hoạt là khi thực thi một khoảng thời gian hết hạn ngắn hơn. Khi đăng ký điều kiện kích hoạt, một công nghệ quảng cáo có thể chỉ định (tính bằng giây) một giai đoạn xem lại kể từ khi lượt chuyển đổi diễn ra. Ví dụ: giai đoạn xem lại 7 ngày sẽ được xác định là: "_lookback_window": 604800 // 7d

API sẽ kiểm tra giai đoạn xem lại trước để quyết định xem một bộ lọc có phù hợp hay không. Nếu phù hợp, khoảng thời gian kể từ khi nguồn được đăng ký phải nhỏ hơn hoặc bằng khoảng thời gian của giai đoạn xem lại.

Lưu ý: Bạn có thể dùng chức năng và logic lọc của giai đoạn xem lại kể từ quý 1 năm 2024. Bạn có thể tìm thêm thông tin cụ thể về thời điểm phát hành. Logic trước đây yêu cầu phải chỉ định giai đoạn xem lại theo giờ, ở cả phía nguồn và phía điều kiện kích hoạt. Logic cập nhật của tính năng này không có khả năng tương thích ngược, tức là các nguồn dùng khoá "_lookback_window" trước đây sẽ không đăng ký được.

Các nền tảng công nghệ quảng cáo cũng có thể chọn kích hoạt dữ liệu dựa trên dữ liệu sự kiện nguồn. Ví dụ: source_type được API tự động tạo dưới dạng navigation hoặc event. Trong quá trình đăng ký điều kiện kích hoạt, trigger_data có thể được đặt làm một giá trị cho "source_type": ["navigation"] và một giá trị khác cho "source_type": ["event"].

Điều kiện kích hoạt sẽ bị loại bỏ khỏi báo cáo cấp sự kiện nếu bất kỳ trường hợp nào sau đây xảy ra:

• Bạn chưa chỉ định trigger_data nào.
• Nguồn và điều kiện kích hoạt chỉ định cùng một khoá bộ lọc, nhưng các giá trị không khớp. Lưu ý rằng trong trường hợp này, điều kiện kích hoạt sẽ bị bỏ qua cho cả báo cáo cấp sự kiện và báo cáo tổng hợp.

Phân bổ sau cài đặt

Trong một số trường hợp, bạn cần phân bổ các điều kiện kích hoạt sau cài đặt cho cùng một nguồn phân bổ dẫn đến lượt cài đặt, ngay cả khi có các nguồn phân bổ đủ điều kiện khác xuất hiện gần đây hơn.

API có thể hỗ trợ trường hợp sử dụng này bằng cách cho phép các công nghệ quảng cáo đặt một khoảng thời gian phân bổ sau cài đặt:

• Khi đăng ký nguồn phân bổ, hãy chỉ định thời lượng phân bổ lượt cài đặt dự kiến, lượt cài đặt dự kiến (thường là 2 – 7 ngày, được chấp nhận trong khoảng từ 1 đến 30 ngày). Chỉ định khoảng thời gian này theo giây.
• Khi đăng ký một nguồn phân bổ, hãy chỉ định thời lượng phân bổ độc quyền sau cài đặt, trong đó mọi sự kiện kích hoạt sau cài đặt đều được liên kết với nguồn phân bổ đã thúc đẩy lượt cài đặt (thường là 7 đến 30 ngày, phạm vi cho phép là từ 0 đến 30 ngày). Chỉ định khoảng thời gian này theo giây.
• Attribution Reporting API xác thực thời điểm diễn ra lượt cài đặt ứng dụng và phân bổ nội bộ lượt cài đặt cho nguồn phân bổ ưu tiên nguồn. Tuy nhiên, lượt cài đặt không được gửi đến các công nghệ quảng cáo và không tính vào giới hạn tỷ lệ tương ứng của nền tảng.
• Mọi ứng dụng đã tải xuống đều có thể xác thực việc cài đặt ứng dụng.
• Mọi điều kiện kích hoạt trong tương lai xảy ra trong thời lượng phân bổ sau cài đặt đều được phân bổ cho cùng một nguồn phân bổ dưới dạng lượt cài đặt đã xác thực, với điều kiện nguồn phân bổ đó đủ điều kiện.

Trong tương lai, chúng tôi có thể tìm hiểu cách mở rộng thiết kế để hỗ trợ các mô hình phân bổ nâng cao hơn.

Bảng sau đây là một ví dụ về cách các công nghệ quảng cáo có thể sử dụng mô hình phân bổ sau cài đặt. Giả sử tất cả nguồn phân bổ và điều kiện kích hoạt đang được đăng ký bởi cùng một mạng công nghệ quảng cáo, đồng thời mọi mức độ ưu tiên đều giống nhau.

Sự kiện	Ngày diễn ra sự kiện	Lưu ý
Nhấp vào 1	1	install_attribution_window được đặt thành172800 (2 ngày) và post_install_exclusivity_window được đặt thành 864000 (10 ngày)
Đã xác minh lượt cài đặt	2	API này phân bổ các lượt cài đặt đã xác minh trong nội bộ, nhưng những lượt cài đặt đó không được coi là điều kiện kích hoạt. Do đó, không có báo cáo nào được gửi vào thời điểm này.
Trình kích hoạt 1 (Mở lần đầu)	2	Trình kích hoạt đầu tiên do công nghệ quảng cáo đăng ký. Ở ví dụ này, nó đại diện cho lần mở đầu tiên nhưng có thể là bất kỳ loại trình kích hoạt nào. Được phân bổ cho lượt nhấp 1 (khớp với lượt phân bổ cho lượt cài đặt đã xác minh).
Nhấp vào 2.	4	Sử dụng các giá trị giống nhau cho install_attribution_window và post_install_exclusivity_window dưới dạng Lượt nhấp 1
Điều kiện kích hoạt 2 (Sau cài đặt)	5	Trình kích hoạt thứ hai do công nghệ quảng cáo đăng ký. Trong ví dụ này, dữ liệu này thể hiện số lượt chuyển đổi sau khi cài đặt, chẳng hạn như một lượt mua hàng. Được phân bổ cho lượt nhấp 1 (khớp với lượt phân bổ cho lượt cài đặt đã xác minh). Lượt nhấp 2 bị loại bỏ và không đủ điều kiện cho hoạt động phân bổ trong tương lai.

Danh sách dưới đây cung cấp thêm một số lưu ý liên quan đến việc phân bổ sau khi cài đặt:

• Nếu số lượt cài đặt đã xác minh không xảy ra trong phạm vi số ngày do install_attribution_window chỉ định, thì thời lượng phân bổ sau cài đặt sẽ không được áp dụng.
• Số lượt cài đặt đã xác minh không phải là do các công nghệ quảng cáo đăng ký và không được gửi đi trong báo cáo. Chúng không được tính vào giới hạn số lượng yêu cầu của công nghệ quảng cáo. Số lượt cài đặt đã xác minh chỉ dùng để xác định nguồn phân bổ được ghi nhận với lượt cài đặt đó.
• Trong ví dụ ở bảng trước, điều kiện kích hoạt 1 và điều kiện kích hoạt 2 lần lượt biểu thị lượt chuyển đổi mở lần đầu và lượt chuyển đổi sau cài đặt. Tuy nhiên, các nền tảng công nghệ quảng cáo có thể đăng ký bất kỳ loại điều kiện kích hoạt nào. Nói cách khác, điều kiện kích hoạt đầu tiên không nhất thiết phải là điều kiện kích hoạt mở đầu tiên.
• Nếu có nhiều điều kiện kích hoạt hơn được đăng ký sau khi post_install_exclusivity_window hết hạn, thì lượt nhấp 1 sẽ vẫn đủ điều kiện để được phân bổ, giả sử thời điểm này chưa hết hạn và chưa đạt đến giới hạn số lượng yêu cầu.
  • Lượt nhấp 1 vẫn có thể bị mất đi hoặc bị loại bỏ nếu nguồn phân bổ có mức độ ưu tiên cao hơn được đăng ký.
• Nếu ứng dụng của nhà quảng cáo bị gỡ rồi cài đặt lại, thì lượt cài đặt lại được tính là một lượt cài đặt mới đã xác minh.
• Nếu lượt nhấp 1 là một sự kiện xem, thì cả điều kiện kích hoạt "mở lần đầu" và điều kiện kích hoạt sau khi cài đặt vẫn được phân bổ cho sự kiện đó. API chỉ cho phép một điều kiện kích hoạt cho mỗi lượt xem, ngoại trừ trường hợp phân bổ sau cài đặt đồng thời cho phép tối đa 2 điều kiện kích hoạt cho mỗi lượt xem. Trong trường hợp phân bổ sau cài đặt, công nghệ quảng cáo có thể nhận được 2 khoảng thời gian báo cáo khác nhau (vào 2 ngày hoặc khi hết hạn nguồn).

Tất cả các cách kết hợp giữa đường dẫn điều kiện kích hoạt dựa trên ứng dụng và dựa trên web đều được hỗ trợ

Attribution Reporting API cho phép phân bổ các đường dẫn sau đây của điều kiện kích hoạt 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ị.

Chúng tôi cho phép các trình duyệt web hỗ trợ chức năng hiển thị trên web mới, chẳng hạn như chức năng tương tự Hộp cát về quyền riêng tư cho API Báo cáo phân bổ của web. Chức năng này có thể gọi API Android để hỗ trợ phân bổ trên ứng dụng và web.

Tìm hiểu về những thay đổi mà các ứng dụng và công nghệ quảng cáo cần thực hiện để hỗ trợ đường dẫn kích hoạt tính năng đo lường trên nhiều ứng dụng và web.

Ưu tiên nhiều điều kiện kích hoạt cho một nguồn phân bổ đơn

Một nguồn phân bổ có thể dẫn đến nhiều trình kích hoạt. Ví dụ: một quy trình mua có thể liên quan đến điều kiện kích hoạt "cài đặt ứng dụng", một hoặc nhiều điều kiện kích hoạt "thêm vào giỏ hàng" và một điều kiện kích hoạt "mua hàng". Mỗi điều kiện kích hoạt được phân bổ cho một hoặc nhiều nguồn phân bổ theo thuật toán phân bổ ưu tiên nguồn, như mô tả ở phần sau của trang này.

Có giới hạn về số điều kiện kích hoạt có thể phân bổ cho một nguồn phân bổ; để biết thêm thông tin chi tiết, hãy đọc cách xem dữ liệu đo lường trong báo cáo phân bổ ở phần sau của trang này. Trong trường hợp có nhiều điều kiện kích hoạt vượt quá các giới hạn này, bạn nên áp dụng logic ưu tiên để khai thác tối đa điều kiện kích hoạt có giá trị nhất. Ví dụ: các nhà phát triển của một công nghệ quảng cáo có thể muốn ưu tiên nhận được điều kiện kích hoạt "mua hàng" hơn là điều kiện kích hoạt "thêm vào giỏ hàng".

Để hỗ trợ logic này, bạn có thể thiết lập một trường mức ưu tiên riêng cho điều kiện kích hoạt. Điều kiện kích hoạt có mức ưu tiên cao nhất sẽ được chọn trước khi áp dụng các giới hạn, trong khoảng thời gian báo cáo nhất định.

Lưu ý: Các điều kiện kích hoạt có mức ưu tiên thấp hơn đã được báo cáo sẽ luôn sử dụng ngân sách.

Cho phép nhiều công nghệ quảng cáo đăng ký các điều kiện kích hoạt hoặc nguồn phân bổ

Thông thường, nhiều công nghệ quảng cáo sẽ nhận được báo cáo phân bổ, nhìn chung là để loại bỏ tình trạng trùng lặp trên nhiều mạng. Do đó, API cho phép nhiều công nghệ quảng cáo đăng ký cùng một điều kiện kích hoạt hoặc nguồn phân bổ. Một công nghệ quảng cáo phải đăng ký cả nguồn phân bổ và điều kiện kích hoạt để nhận các lượt đăng lại từ API, còn việc phân bổ sẽ được thực hiện giữa các nguồn phân bổ và điều kiện kích hoạt mà công nghệ quảng cáo đã đăng ký với API.

Nhà quảng cáo muốn sử dụng bên thứ ba để loại bỏ trùng lặp trên nhiều mạng có thể tiếp tục làm như vậy bằng kỹ thuật tương tự như cách sau đây:

• Thiết lập máy chủ nội bộ để đăng ký và nhận báo cáo từ API.
• Tiếp tục sử dụng một đối tác đo lường hiện có trên thiết bị di động.

Nguồn phân bổ

Các lệnh chuyển hướng nguồn phân bổ được hỗ trợ trong phương thức registerSource():

1. Công nghệ quảng cáo gọi phương thức registerSource() có thể cung cấp một trường Attribution-Reporting-Redirect bổ sung trong phản hồi. Trường này đại diện cho một tập hợp URL chuyển hướng thuộc công nghệ quảng cáo của đối tác.
2. Sau đó, API sẽ gọi URL chuyển hướng, nhờ đó, nguồn phân bổ có thể được đăng ký bằng công nghệ quảng cáo của đối tác.

Có thể liệt kê nhiều URL thuộc công nghệ quảng cáo của đối tác trong trường Attribution-Reporting-Redirect và các công nghệ quảng cáo của đối tác không thể chỉ định trường Attribution-Reporting-Redirect của riêng công nghệ quảng cáo đó.

API này cũng hỗ trợ nhiều công nghệ quảng cáo cho mỗi lệnh gọi registerSource().

Điều kiện kích hoạt

Để đăng ký điều kiện kích hoạt, các bên thứ ba được hỗ trợ theo cách tương tự: các công nghệ quảng cáo có thể sử dụng trường Attribution-Reporting-Redirect bổ sung hoặc mỗi công nghệ quảng cáo có thể gọi phương thức registerTrigger().

Khi nhà quảng cáo sử dụng nhiều công nghệ quảng cáo để đăng ký cùng một sự kiện cho điều kiện kích hoạt, bạn nên dùng khoá loại bỏ trùng lặp. Khoá loại bỏ trùng lặp đóng vai trò phân biệt những báo cáo lặp lại của cùng một sự kiện do cùng một nền tảng công nghệ quảng cáo đăng ký. Ví dụ: một công nghệ quảng cáo có thể yêu cầu SDK trực tiếp gọi API để đăng ký điều kiện kích hoạt và đặt URL trong trường chuyển hướng thuộc lệnh gọi của một công nghệ quảng cáo khác. Nếu không cung cấp khoá loại bỏ trùng lặp, thì các điều kiện kích hoạt trùng lặp có thể được báo cáo ngược lại đến từng công nghệ quảng cáo dưới dạng một điều kiện kích hoạt duy nhất.

Xử lý các điều kiện kích hoạt trùng lặp

Một công nghệ quảng cáo có thể đăng ký cùng một điều kiện kích hoạt nhiều lần bằng API. Sau đây là các trường hợp có thể xảy ra:

• Người dùng thực hiện cùng một thao tác (điều kiện kích hoạt) nhiều lần. Ví dụ: người dùng duyệt xem cùng một sản phẩm nhiều lần trong cùng một khoảng thời gian báo cáo.
• Ứng dụng của nhà quảng cáo sử dụng nhiều SDK để đo lường lượt chuyển đổi, tất cả đều chuyển hướng đến cùng một công nghệ quảng cáo. Ví dụ: ứng dụng của nhà quảng cáo sử dụng 2 đối tác đo lường là MMP #1 và MMP #2. Cả hai MMP đều chuyển hướng đến công nghệ quảng cáo #3. Khi một điều kiện kích hoạt xảy ra, cả hai MMP đều đăng ký điều kiện kích hoạt đó bằng API Báo cáo phân bổ. Tiếp đến, công nghệ quảng cáo #3 nhận được 2 lệnh chuyển hướng riêng biệt – một từ MMP #1 và một từ MMP #2 – cho cùng một điều kiện kích hoạt.

Trong những trường hợp như vậy, có một số cách để chặn các báo cáo cấp sự kiện đối với điều kiện kích hoạt trùng lặp, nhằm giảm khả năng vượt quá giới hạn số lượng yêu cầu áp dụng cho các báo cáo cấp sự kiện. Bạn nên dùng khoá loại bỏ trùng lặp.

Phương pháp đề xuất: khoá loại bỏ trùng lặp

Phương thức đề xuất cho ứng dụng của nhà quảng cáo là truyền khoá loại bỏ trùng lặp duy nhất cho mọi công nghệ quảng cáo hoặc SDK mà ứng dụng đang sử dụng để đo lường lượt chuyển đổi. Khi xảy ra một lượt chuyển đổi, ứng dụng sẽ truyền khoá loại bỏ trùng lặp cho các công nghệ quảng cáo hoặc SDK. Sau đó, các công nghệ quảng cáo hoặc SDK đó sẽ tiếp tục truyền khoá loại bỏ trùng lặp sang các lệnh chuyển hướng bằng cách sử dụng một tham số trong các URL được chỉ định trong Attribution-Reporting-Redirect.

Các công nghệ quảng cáo có thể chọn chỉ đăng ký điều kiện kích hoạt đầu tiên bằng một khoá loại bỏ trùng lặp nhất định hoặc có thể chọn đăng ký nhiều/tất cả điều kiện kích hoạt. Các công nghệ quảng cáo có thể chỉ định deduplication_key khi đăng ký các điều kiện kích hoạt trùng lặp.

Nếu một công nghệ quảng cáo đăng ký nhiều điều kiện kích hoạt bằng cùng một khoá loại bỏ trùng lặp và nguồn được phân bổ, thì chỉ có điều kiện kích hoạt đã đăng ký đầu tiên sẽ được gửi trong báo cáo cấp sự kiện. Những điều kiện kích hoạt trùng lặp vẫn được gửi trong các báo cáo tổng hợp đã mã hoá.

Phương pháp thay thế: các công nghệ quảng cáo đưa ra thoả thuận thống nhất về các loại điều kiện kích hoạt cho mỗi nhà quảng cáo

Trong các trường hợp công nghệ quảng cáo không muốn sử dụng khoá loại bỏ trùng lặp hoặc khi ứng dụng của nhà quảng cáo không thể truyền khoá loại bỏ trùng lặp, lựa chọn thay thế sẽ được sử dụng. Tất cả công nghệ quảng cáo đo lường lượt chuyển đổi của một nhà quảng cáo nhất định cần phải phối hợp với nhau để xác định các loại điều kiện kích hoạt cho từng nhà quảng cáo.

Các công nghệ quảng cáo gửi lệnh gọi đăng ký điều kiện kích hoạt (chẳng hạn các SDK) chứa một tham số trong các URL được chỉ định trong Attribution-Reporting-Redirect, chẳng hạn như duplicate_trigger_id. Tham số duplicate_trigger_id đó có thể bao gồm các thông tin như tên SDK và loại điều kiện kích hoạt cho nhà quảng cáo đó. Sau đó, công nghệ quảng cáo có thể gửi một tập hợp con các điều kiện kích hoạt trùng lặp này tới báo cáo cấp sự kiện. Các công nghệ quảng cáo cũng có thể đưa duplicate_trigger_id này vào khoá tổng hợp của mình.

Ví dụ về mô hình phân bổ trên nhiều mạng

Ở ví dụ mô tả trong phần này, nhà quảng cáo đang sử dụng 2 nền tảng công nghệ quảng cáo phân phát (Công nghệ quảng cáo A và Công nghệ quảng cáo B) và một đối tác đo lường (MMP).

Để bắt đầu, từng Công nghệ quảng cáo A, Công nghệ quảng cáo B và MMP phải hoàn tất đăng ký để sử dụng 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 đây là danh sách một loạt hành động giả định của người dùng sẽ diễn ra lần lượt từng ngày và cách Attribution Reporting API xử lý những hành động đó đối với Công nghệ quảng cáo A, Công nghệ quảng cáo B và MMP:

Ngày 1: Người dùng nhấp vào quảng cáo do Công nghệ quảng cáo A phân phát

Công nghệ quảng cáo A gọi registerSource() bằng URI của mình. API gửi yêu cầu đến URI và lượt nhấp đó được đăng ký bằng siêu dữ liệu lấy từ phản hồi của máy chủ Công nghệ quảng cáo A.

Công nghệ quảng cáo A cũng đưa URI của MMP vào tiêu đề Attribution-Reporting-Redirect. API gửi yêu cầu đến URI của MMP và lượt nhấp đó được đăng ký bằng siêu dữ liệu lấy từ phản hồi của máy chủ phía MMP.

Ngày 2: Người dùng nhấp vào quảng cáo do Công nghệ quảng cáo B phân phát

Công nghệ quảng cáo B gọi registerSource() bằng URI của mình. API gửi yêu cầu đến URI và lượt nhấp đó được đăng ký bằng siêu dữ liệu lấy từ phản hồi của máy chủ Công nghệ quảng cáo B.

Giống như Công nghệ quảng cáo A, Công nghệ quảng cáo B cũng đưa URI của MMP vào tiêu đề Attribution-Reporting-Redirect. API gửi yêu cầu đến URI của MMP và lượt nhấp đó được đăng ký bằng siêu dữ liệu lấy từ phản hồi của máy chủ phía MMP.

Ngày 3: Người dùng xem quảng cáo do Công nghệ quảng cáo A phân phát

API phản hồi theo cách giống như đã thực hiện vào Ngày 1, ngoại trừ việc một lượt xem được đăng ký cho Công nghệ quảng cáo A và MMP.

Ngày 4: Người dùng cài đặt ứng dụng và ứng dụng này dùng MMP để đo lường lượt chuyển đổi

MMP gọi registerTrigger() bằng URI của họ. API gửi yêu cầu đến URL và lượt chuyển đổi đó được đăng ký bằng siêu dữ liệu lấy từ phản hồi của máy chủ phía MMP.

MMP cũng đưa các URI của Công nghệ quảng cáo A và Công nghệ quảng cáo B vào tiêu đề Attribution-Reporting-Redirect. API gửi yêu cầu đến máy chủ của Công nghệ quảng cáo A và Công nghệ quảng cáo B, sau đó lượt chuyển đổi được đăng ký tương ứng bằng siêu dữ liệu lấy từ các phản hồi của máy chủ.

Hình 1 minh hoạ quy trình được mô tả trong danh sách trước đó:

Hình 1. Ví dụ về cách API Báo cáo phân bổ phản hồi một loạt hành động của người dùng.

Mô hình phân bổ hoạt động như sau:

• Công nghệ quảng cáo A đặt mức độ ưu tiên của lượt nhấp cao hơn lượt xem nên lượt cài đặt đã được phân bổ cho lượt nhấp vào Ngày 1.
• Công nghệ quảng cáo B nhận được lượt cài đặt được phân bổ vào Ngày 2.
• MMP đặt mức độ ưu tiên của lượt nhấp cao hơn lượt xem nên lượt cài đặt đã được phân bổ cho lượt nhấp vào Ngày 2. Lượt nhấp vào ngày thứ 2 là sự kiện quảng cáo có mức độ ưu tiên cao nhất và gần đây nhất.

Phân bổ trên nhiều mạng mà không cần chuyển hướng

Mặc dù bạn nên sử dụng các lệnh chuyển hướng để cho phép nhiều công nghệ quảng cáo đăng ký các điều kiện kích hoạt và nguồn phân bổ, nhưng chúng tôi nhận thấy có thể xảy ra những trường hợp không thể dùng lệnh chuyển hướng. Phần này sẽ trình bày chi tiết về cách hỗ trợ hoạt động phân bổ trên nhiều mạng mà không cần chuyển hướng.

Luồng cấp cao

1. Khi đăng ký nguồn, mạng công nghệ quảng cáo phân phát chia sẻ các khoá tổng hợp nguồn của chúng.
2. Khi đăng ký điều kiện kích hoạt, nhà quảng cáo hoặc đối tác đo lường sẽ chọn phần khoá phía nguồn để sử dụng và chỉ định cấu hình phân bổ.
3. Hoạt động phân bổ dựa trên cấu hình phân bổ, khoá dùng chung và mọi nguồn đã được nhà quảng cáo hoặc đối tác đo lường đăng ký trên thực tế (ví dụ: từ một mạng công nghệ quảng cáo phân phát khác đã bật tính năng chuyển hướng).
4. Nếu điều kiện kích hoạt được phân bổ cho một nguồn qua công nghệ quảng cáo phân phát không chuyển hướng, thì nhà quảng cáo hoặc đối tác đo lường có thể nhận được báo cáo tổng hợp cả phần khoá phía nguồn và phần khoá điều kiện kích hoạt xác định được ở bước 2.

Đăng ký nguồn

Khi đăng ký nguồn, mạng công nghệ quảng cáo phân phát có thể chọn chia sẻ các khoá tổng hợp nguồn của chúng hoặc một tập hợp con gồm các khoá tổng hợp nguồn thay vì chuyển hướng. Công nghệ quảng cáo phân phát không bắt buộc phải dùng các khoá nguồn này trong báo cáo tổng hợp của chúng trên thực tế và chỉ có thể khai báo các khoá này thay cho nhà quảng cáo hoặc đối tác đo lường nếu cần.

Khoá tổng hợp dùng chung có sẵn cho bất kỳ công nghệ quảng cáo nào đăng ký điều kiện kích hoạt cho cùng một nhà quảng cáo. Tuy nhiên, việc tìm ra loại khoá tổng hợp cần thiết, tên của những khoá đó và cách giải mã khoá thành các phương diện dễ đọc là nhiệm vụ của công nghệ quảng cáo phân phát và công nghệ quảng cáo đo lường điều kiện kích hoạt.

Đăng ký điều kiện kích hoạt

Khi đăng ký điều kiện kích hoạt, công nghệ quảng cáo đo lường sẽ chọn những phần khoá phía nguồn để áp dụng cho từng phần khoá điều kiện kích hoạt, bao gồm cả phần được chia sẻ bằng cách phân phát công nghệ quảng cáo.

Ngoài ra, công nghệ quảng cáo đo lường cũng phải chỉ định logic phân bổ thác nước (waterfall) thông qua lệnh gọi API cấu hình phân bổ mới. Trong cấu hình này, công nghệ quảng cáo có thể chỉ định mức độ ưu tiên, thời gian hết hạn và bộ lọc cho các nguồn không có chế độ hiển thị (ví dụ: các nguồn không sử dụng lệnh chuyển hướng).

Phân bổ

Attribution Reporting API thực hiện mô hình phân bổ theo lần chạm sau cùng, ưu tiên nguồn cho công nghệ quảng cáo đo lường dựa trên cấu hình phân bổ, khoá dùng chung và bất kỳ nguồn nào mà chúng đã đăng ký. Ví dụ:

• Người dùng nhấp vào quảng cáo do các công nghệ quảng cáo A, B, C và D phân phát. Sau đó, người dùng cài đặt ứng dụng của nhà quảng cáo. Ứng dụng này sử dụng một đối tác công nghệ quảng cáo đo lường (MMP).
• Công nghệ quảng cáo A chuyển hướng nguồn của nó đến MMP.
• Công nghệ quảng cáo B và C không chuyển hướng nhưng dùng chung khoá tổng hợp của chúng.
• Công nghệ quảng cáo D không chuyển hướng cũng như không dùng chung khoá tổng hợp.

MMP đăng ký nguồn từ Công nghệ quảng cáo A và xác định cấu hình phân bổ bao gồm Công nghệ quảng cáo B và Công nghệ quảng cáo D.

Mô hình phân bổ cho MMP hiện bao gồm:

• Công nghệ quảng cáo A, vì MMP đã đăng ký nguồn từ lệnh chuyển hướng của công nghệ quảng cáo đó.
• Công nghệ quảng cáo B, vì Công nghệ quảng cáo B đã chia sẻ khoá và MMP đã đưa khoá đó vào cấu hình phân bổ của họ.

Mô hình phân bổ cho MMP không bao gồm:

• Công nghệ quảng cáo C, vì MMP không đưa công nghệ này vào cấu hình phân bổ của họ.
• Công nghệ quảng cáo D, vì Công nghệ quảng cáo D không chuyển hướng cũng như không chia sẻ khoá tổng hợp.

Lưu ý: Để biết thêm thông tin về cách triển khai thiết kế này, vui lòng đọc tài liệu Hướng dẫn của nhà phát triển về Attribution Reporting API.

Gỡ lỗi

Để hỗ trợ gỡ lỗi khi phân bổ trên nhiều mạng mà không có lệnh chuyển hướng, các công nghệ quảng cáo có thể đặt trường bổ sung shared_debug_key khi đăng ký nguồn. Nếu được đặt khi đăng ký nguồn ban đầu, thì hệ thống cũng sẽ đặt trường này trên nguồn phái sinh tương ứng dưới dạng debug_key trong quá trình đăng ký điều kiện kích hoạt để phân bổ trên nhiều mạng mà không có lệnh chuyển hướng. Khoá gỡ lỗi này được đính kèm dưới dạng source_debug_key trong các báo cáo tổng hợp và báo cáo sự kiện.

Tính năng gỡ lỗi này sẽ chỉ được hỗ trợ cho mô hình phân bổ trên nhiều mạng mà không có lệnh chuyển hướng trong các trường hợp sau:

• Phép đo lường ứng dụng với ứng dụng, trong đó chấp nhận mã nhận dạng cho quảng cáo (AdId)
• Phép đo lường ứng dụng với web khi AdId được chấp nhận và so khớp trên cả nguồn ứng dụng và điều kiện kích hoạt web
• Phép đo lường web với web (trên cùng một ứng dụng trình duyệt) khi ar_debug có trên cả nguồn và điều kiện kích hoạt

Tính năng khám phá khoá để phân bổ trên nhiều mạng mà không cần lệnh chuyển hướng

Tính năng khám phá khoá nhằm đơn giản hoá cách các công nghệ quảng cáo (thường là MMP) triển khai cấu hình phân bổ cho mục đích phân bổ trên nhiều mạng khi một hoặc nhiều công nghệ quảng cáo phân phát đang sử dụng khoá tổng hợp dùng chung (như mô tả trong phần [Phân bổ trên nhiều mạng mà không cần lệnh chuyển hướng][45] ở trên).

Khi một MMP truy vấn Dịch vụ tổng hợp để tạo các báo cáo tóm tắt cho các chiến dịch có chứa các nguồn phát sinh, Dịch vụ tổng hợp sẽ yêu cầu MMP chỉ định danh sách các khoá có thể dùng làm dữ liệu đầu vào cho công việc tổng hợp. Trong một số trường hợp, danh sách các khoá tổng hợp của nguồn tiềm năng có thể rất lớn hoặc không xác định. Việc theo dõi các danh sách gồm nhiều khoá dùng được là rất khó, cũng có thể khá phức tạp và tốn kém chi phí xử lý. Hãy xem các ví dụ sau đây:

• Danh sách gồm nhiều khoá dùng được:
  • Một mạng quảng cáo phân phát đang thực thi một sáng kiến phức tạp về thu nạp người dùng, bao gồm 20 chiến dịch, mỗi chiến dịch có 10 nhóm quảng cáo và mỗi nhóm quảng cáo có 5 mẫu quảng cáo được làm mới mỗi tuần dựa trên hiệu suất.
• Không xác định được danh sách tất cả các khoá dùng được:
  • Mạng quảng cáo phân phát đang phân phát quảng cáo trên nhiều ứng dụng di động, trong đó không xác định được danh sách đầy đủ mã ứng dụng của nhà xuất bản khi khởi chạy chiến dịch.
  • Một nhà quảng cáo đang hoạt động trên nhiều mạng quảng cáo phân phát không chuyển hướng đến MMP khi đăng ký nguồn; mỗi mạng quảng cáo phân phát có các giá trị và một cấu trúc khoá khác, có thể không được chia sẻ trước với MMP.

Có phần giới thiệu về sự kiện khám phá khoá:

• Dịch vụ tổng hợp không còn yêu cầu liệt kê đầy đủ các khoá tổng hợp dùng được.
• Thay vì phải chỉ định danh sách đầy đủ các khoá dùng được, MMP có thể tạo một bộ khoá trống (hoặc trống một phần) và đặt một ngưỡng để chỉ các khoá (chưa được khai báo trước) có các giá trị vượt quá ngưỡng được đưa vào kết quả.
• MMP nhận được báo cáo tóm tắt bao gồm các giá trị gây nhiễu cho các khoá có giá trị đóng góp trên ngưỡng đã đặt. Báo cáo cũng có thể bao gồm các khoá không có đóng góp thực của người dùng được liên kết và chỉ đơn thuần bị nhiễu.
• MMP sử dụng trường x_network_bit_mapping trong quy trình đăng ký điều kiện kích hoạt để xác định công nghệ quảng cáo tương ứng với khoá nào.
• Sau đó, MMP có thể liên hệ với công nghệ quảng cáo phân phát thích hợp để tìm hiểu các giá trị trong khoá nguồn.

Tóm lại, tính năng khám phá khoá cho phép MMP lấy khoá tổng hợp mà không cần biết trước các khoá đó và tránh phải xử lý một lượng lớn các khoá nguồn khiến độ nhiễu tăng.

Lưu ý: Tính năng này đang trong giai đoạn đề xuất và chưa được thử nghiệm. Chúng tôi rất mong nhận được ý kiến phản hồi và nhận xét của bạn.

Xem dữ liệu đo lường trong báo cáo phân bổ

API Báo cáo phân bổ hỗ trợ các loại báo cáo sau đây, được mô tả chi tiết hơn ở phần sau của trang này:

• Báo cáo cấp sự kiện liên kết một nguồn phân bổ cụ thể (lượt nhấp hoặc lượt xem) với các bit giới hạn của dữ liệu điều kiện kích hoạt có độ trung thực cao.
• Báo cáo tổng hợp không nhất thiết phải liên kết với một nguồn phân bổ cụ thể. Những báo cáo này cung cấp dữ liệu điều kiện kích hoạt phong phú hơn, có độ chân thực cao hơn so với báo cáo cấp sự kiện, nhưng dữ liệu này chỉ có ở dạng tổng hợp.

2 loại báo cáo này bổ sung cho nhau và có thể được dùng đồng thời.

Báo cáo cấp sự kiện

Sau khi điều kiện kích hoạt được phân bổ cho một nguồn phân bổ, một báo cáo cấp sự kiện sẽ được tạo và lưu trữ trên thiết bị cho đến khi được gửi trở lại cho URL đăng lại của từng công nghệ quảng cáo trong mộtkhoảng thời gian gửi báo cáo. Thông tin mô tả chi tiết hơn có ở phần sau của trang này.

Các báo cáo cấp sự kiện rất hữu ích do cần rất ít thông tin về điều kiện kích hoạt. Dữ liệu điều kiện kích hoạt cấp sự kiện được giới hạn ở 3 bit dữ liệu điều kiện kích hoạt đối với lượt nhấp (nghĩa là một điều kiện kích hoạt có thể được chỉ định vào 1 trong số 8 danh mục) và 1 bit đối với lượt xem. Ngoài ra, các báo cáo cấp sự kiện không hỗ trợ việc mã hoá dữ liệu phía điều kiện kích hoạt có độ trung thực cao, chẳng hạn như giá cụ thể hoặc thời gian kích hoạt. Vì quy trình phân bổ diễn ra trên thiết bị nên báo cáo cấp sự kiện không hỗ trợ phân tích trên nhiều thiết bị.

Báo cáo cấp sự kiện chứa các dữ liệu như sau:

• Đích đến: Tên gói ứng dụng hoặc eTLD+1 của nhà quảng cáo nơi xảy ra điều kiện kích hoạt
• Mã nhận dạng nguồn phân bổ: Mã nhận dạng nguồn phân bổ được dùng để đăng ký nguồn phân bổ
• Loại điều kiện kích hoạt: 1 hoặc 3 bit dữ liệu điều kiện kích hoạt có độ chân thực thấp, tuỳ theo loại nguồn phân bổ

Cơ chế bảo đảm quyền riêng tư áp dụng cho mọi báo cáo

Các giới hạn sau được áp dụng sau khi xem xét mức ưu tiên về nguồn phân bổ và điều kiện kích hoạt.

Giới hạn về số lượng công nghệ quảng cáo

Có giới hạn về số lượng công nghệ quảng cáo có thể đăng ký hoặc nhận báo cáo từ API, với đề xuất hiện tại như sau:

• 100 công nghệ quảng cáo có nguồn phân bổ cho mỗi {ứng dụng nguồn, ứng dụng đích, trong 30 ngày, thiết bị}.
• 10 công nghệ quảng cáo có điều kiện kích hoạt được phân bổ cho mỗi {ứng dụng nguồn, ứng dụng đích, trong 30 ngày, thiết bị}.
• 20 công nghệ quảng cáo có thể đăng ký một điều kiện kích hoạt hoặc nguồn phân bổ (thông qua Attribution-Reporting-Redirect)

Giới hạn về số lượng các điểm đến duy nhất

Những giới hạn này khiến một nhóm công nghệ quảng cáo khó liên kết với nhau bằng cách truy vấn một số lượng lớn các ứng dụng nhằm hiểu rõ hành vi dùng ứng dụng của một người dùng nhất định.

• Trên tất cả các nguồn đã đăng ký, trên mọi công nghệ quảng cáo, API hỗ trợ không quá 200 điểm đến riêng biệt (mỗi ứng dụng nguồn) mỗi phút.
• Trên tất cả các nguồn đã đăng ký, đối với một công nghệ quảng cáo duy nhất, API hỗ trợ không quá 50 điểm đến riêng biệt (mỗi ứng dụng nguồn) mỗi phút. Giới hạn này ngăn không cho một công nghệ quảng cáo sử dụng hết toàn bộ ngân sách trong giới hạn số lượng yêu cầu đã đề cập trước đó.

Các nguồn đã hết hạn sẽ không được tính vào giới hạn số lượng yêu cầu.

Một nguồn gốc báo cáo cho mỗi ứng dụng nguồn mỗi ngày

Mỗi ngày, một nền tảng công nghệ quảng cáo nhất định chỉ có thể sử dụng một nguồn gốc báo cáo để đăng ký các nguồn trên ứng dụng của nhà xuất bản cho một thiết bị cụ thể. Mức giới hạn này giúp ngăn công nghệ quảng cáo sử dụng nhiều nguồn gốc báo cáo để tiếp cận thêm hạn mức về quyền riêng tư.

Hãy xem xét trường hợp sau (một công nghệ quảng cáo muốn sử dụng nhiều nguồn gốc báo cáo để đăng ký nguồn trên ứng dụng của nhà xuất bản cho một thiết bị).

1. Nguồn gốc báo cáo 1 của công nghệ quảng cáo A đăng ký nguồn trên Ứng dụng B
2. 12 giờ sau, nguồn gốc báo cáo 2 của công nghệ quảng cáo A tiếp tục đăng ký nguồn trên Ứng dụng B

API sẽ từ chối nguồn gốc báo cáo 2 của công nghệ quảng cáo A. Nguồn gốc báo cáo 2 của công nghệ quảng cáo A sẽ không thể đăng ký thành công nguồn trên cùng một thiết bị với Ứng dụng B cho đến ngày hôm sau.

Thời gian quan sát thêm và hạn mức

Để hạn chế việc danh tính người dùng bị rò rỉ giữa một cặp {nguồn, đích}, API sẽ điều tiết tổng lượng thông tin được gửi trong một khoảng thời gian nhất định cho người dùng.

Đề xuất hiện tại giới hạn mỗi công nghệ quảng cáo ở mức 100 điều kiện kích hoạt được phân bổ cho mỗi {ứng dụng nguồn, ứng dụng đích, trong 30 ngày, thiết bị}.

Số lượng đích đến duy nhất

API này giới hạn số lượng đích đến mà một công nghệ quảng cáo có thể đo lường được. Giới hạn càng thấp thì công nghệ quảng cáo càng khó sử dụng API để đo lường hoạt động duyệt web của người dùng không liên kết với quảng cáo đang hiển thị.

Đề xuất hiện tại là giới hạn mỗi công nghệ quảng cáo ở mức 100 đích đến riêng biệt với các nguồn chưa hết hạn cho mỗi ứng dụng nguồn.

Cơ chế bảo đảm quyền riêng tư áp dụng cho các báo cáo cấp sự kiện

Độ trung thực hạn chế của dữ liệu điều kiện kích hoạt

API này cung cấp 1 bit đối với điều kiện kích hoạt lượt xem hết và 3 bit đối với điều kiện kích hoạt lượt nhấp. Các nguồn phân bổ tiếp tục hỗ trợ 64 bit siêu dữ liệu đầy đủ.

Bạn nên đánh giá xem liệu có cần và cách giảm bớt thông tin biểu thị trong các điều kiện kích hoạt để chúng hoạt động với số lượng bit giới hạn có trong báo cáo cấp sự kiện.

Khung của hiện tượng nhiễu liên quan đến sự riêng tư biệt lập

Mục tiêu của API này là cho phép đo lường ở cấp sự kiện để đáp ứng các yêu cầu cục bộ về quyền riêng tư biệt lập bằng cách sử dụng phản hồi được sắp xếp ngẫu nhiên nhằm tạo đầu ra nhiễu cho từng sự kiện nguồn.

Độ nhiễu được áp dụng khi xác định xem một sự kiện nguồn phân bổ có được báo cáo chính xác không. Một nguồn phân bổ được đăng ký trên thiết bị với xác suất $ 1-p $ mà nguồn phân bổ này được đăng ký như bình thường, với xác suất $ p $ mà thiết bị lựa chọn ngẫu nhiên trong số tất cả trạng thái đầu ra có thể có của API (bao gồm cả không báo cáo hoặc đưa ra nhiều báo cáo giả).

Phản hồi được sắp xếp ngẫu nhiên k là một thuật toán riêng tư biệt lập epsilon nếu thoả mãn phương trình sau đây:

\[p = \frac{k}{k + e^ε - 1}\]

Đối với các giá trị ε thấp, đầu ra thực sự được bảo vệ bằng cơ chế phản hồi được sắp xếp ngẫu nhiên k. Các thông số nhiễu chính xác đang trong quá trình tính toán và có thể thay đổi dựa trên ý kiến phản hồi, với đề xuất hiện tại như sau:

• p=0,24% đối với nguồn điều hướng
• p=0,00025% đối với nguồn sự kiện

Giới hạn về số điều kiện kích hoạt hiện có (hành vi mặc định)

Có giới hạn mặc định về số lượng điều kiện kích hoạt (lượt chuyển đổi) trên mỗi nguồn phân bổ:

• 1 – 2 điều kiện kích hoạt cho nguồn phân bổ lượt xem quảng cáo (chỉ có 2 điều kiện kích hoạt trong trường hợp phân bổ sau cài đặt)
• 3 trình kích hoạt cho nguồn phân bổ nhấp vào quảng cáo

Lưu ý: Phần này mô tả hành vi mặc định của API cho số lượt phân bổ trên mỗi nguồn bằng cách sử dụng tính năng báo cáo ở cấp sự kiện. Nhờ việc giới thiệu báo cáo linh hoạt ở cấp sự kiện vào tháng 10 năm 2023, mà các công nghệ quảng cáo giờ đây có thể định cấu hình phương diện này trong báo cáo dựa trên phương diện phù hợp nhất với trường hợp sử dụng của họ.

Khoảng thời gian cụ thể để gửi báo cáo (hành vi mặc định)

Các báo cáo ở cấp sự kiện về nguồn phân bổ lượt xem quảng cáo sẽ được gửi sau khi nguồn hết hạn. Ngày hết hạn này có thể được định cấu hình, nhưng không được ít hơn 1 ngày hoặc nhiều hơn 30 ngày. Nếu 2 điều kiện kích hoạt được phân bổ cho một nguồn phân bổ lượt xem quảng cáo (thông qua tuỳ chọn phân bổ sau khi cài đặt), thì báo cáo ở cấp sự kiện có thể được gửi theo khoảng thời gian báo cáo được chỉ định ở bên dưới.

Các báo cáo ở cấp sự kiện về nguồn phân bổ lượt nhấp vào quảng cáo được gửi trước khi hoặc khi nguồn hết hạn, vào một thời điểm được chỉ định tương ứng với thời điểm nguồn được đăng ký. Thời gian từ nguồn phân bổ cho đến thời hạn được chia thành nhiều khoảng thời gian báo cáo. Mỗi khoảng thời gian báo cáo có một hạn cuối (từ thời gian nguồn phân bổ). Vào cuối mỗi khoảng thời gian báo cáo, thiết bị sẽ thu thập tất cả các điều kiện kích hoạt đã diễn ra kể từ thời gian báo cáo trước đó và gửi một báo cáo định kỳ. API hỗ trợ các khoảng thời gian báo cáo mặc định sau đây:

• 2 ngày: Thiết bị thu thập tất cả các điều kiện kích hoạt đã diễn ra tối đa là 2 ngày sau khi nguồn phân bổ được đăng ký và gửi báo cáo.
• 7 ngày: Thiết bị thu thập tất cả các điều kiện kích hoạt đã diễn ra hơn 2 ngày nhưng không quá 7 ngày sau khi nguồn phân bổ được đăng ký và gửi báo cáo.
• Khoảng thời gian tuỳ chỉnh, được xác định bởi thuộc tính "expiry" (hết hạn) của một nguồn phân bổ. Báo cáo được gửi sau thời gian hết hạn đã chỉ định, không được dưới 1 ngày hoặc nhiều hơn 30 ngày.

Lưu ý: Phần này mô tả hành vi mặc định của API trong khoảng thời gian báo cáo ở cấp sự kiện. Nhờ việc giới thiệu báo cáo linh hoạt ở cấp sự kiện vào tháng 10 năm 2023, mà các công nghệ quảng cáo giờ đây có thể định cấu hình khoảng thời gian báo cáo dựa trên khoảng thời gian phù hợp nhất với trường hợp sử dụng của họ.

Cấu hình linh hoạt ở cấp sự kiện

Cấu hình mặc định của báo cáo cấp sự kiện là cấu hình mà công nghệ quảng cáo nên bắt đầu sử dụng khi bắt đầu thử nghiệm phần mềm tiện ích, nhưng có thể không phù hợp với tất cả các trường hợp sử dụng. Attribution Reporting API sẽ hỗ trợ các cấu hình tuỳ chọn và linh hoạt hơn để công nghệ quảng cáo có thể tăng mức kiểm soát cấu trúc của các báo cáo cấp sự kiện và có thể tối đa hoá dịch vụ tiện ích của dữ liệu.

Tính linh hoạt bổ sung này sẽ được đưa vào Attribution Reporting API theo hai giai đoạn:

• Giai đoạn 1: Cấu hình cấp sự kiện linh hoạt và thu gọn
  • Phiên bản này cung cấp một tập hợp con đầy đủ các tính năng và có thể được sử dụng độc lập với Giai đoạn 2.
• Giai đoạn 2: Phiên bản đầy đủ của cấu hình cấp sự kiện linh hoạt

Bạn có thể sử dụng Giai đoạn 1 (Cấp sự kiện linh hoạt và thu gọn) để:

• Thay đổi tần suất của báo cáo bằng cách chỉ định số lượng khoảng thời gian báo cáo
• Thay đổi số lượt phân bổ trên mỗi lượt đăng ký nguồn
• Giảm tổng độ nhiễu bằng cách giảm các thông số trên
• Định cấu hình khoảng thời gian báo cáo thay vì sử dụng giá trị mặc định

Bạn có thể sử dụng Giai đoạn 2 (Cấp sự kiện hoàn toàn linh hoạt) để thực hiện tất cả các tính năng trong Giai đoạn 1 và:

• Thay đổi lượng dữ liệu kích hoạt trong báo cáo
• Giảm tổng độ nhiễu bằng cách giảm lượng dữ liệu kích hoạt

Việc giảm một kích thước của cấu hình mặc định cho phép công nghệ quảng cáo tăng một kích thước khác. Ngoài ra, tổng độ nhiễu trong báo cáo cấp sự kiện có thể giảm bằng cách giảm thuần các thông số nêu trên.

Ngoài việc tự động đặt độ nhiễu dựa trên cấu hình đã chọn của công nghệ quảng cáo, chúng tôi sẽ có một số giới hạn thông số để tránh chi phí tính toán lớn và các cấu hình có quá nhiều trạng thái đầu ra (trong đó độ nhiễu sẽ tăng đáng kể). Dưới đây là một bộ hạn chế mẫu. Chúng tôi rất mong nhận được ý kiến phản hồi về [đề xuất thiết kế][52]:

• Tổng cộng tối đa là 20 báo cáo trên toàn cầu và theo mỗi dữ liệu_điều kiện kích hoạt
• Tối đa là 5 khoảng thời gian báo cáo có thể xảy ra theo mỗi dữ liệu_kích hoạt
• Tối đa là 32 lượng số dữ liệu kích hoạt (không áp dụng cho Giai đoạn 1: Cấp sự kiện linh hoạt và thu gọn)

Khi các công nghệ quảng cáo bắt đầu sử dụng tính năng này, lưu ý rằng việc sử dụng các giá trị cực đại có thể dẫn đến độ nhiễu cao hoặc không đăng ký được nếu không đáp ứng các cấp độ bảo mật.

Lưu ý: Giai đoạn 1 (Cấp sự kiện rút gọn linh hoạt) dự kiến sẽ phát hành dưới dạng bản beta vào tháng 10 năm 2023. Giai đoạn 2 (Cấp sự kiện hoàn toàn linh hoạt) dự kiến sẽ phát hành dưới dạng bản beta vào cuối Quý 1 năm 2024.

Các báo cáo tổng hợp

Trước khi sử dụng báo cáo tổng hợp, bạn phải [thiết lập][53] tài khoản đám mây và bắt đầu nhận báo cáo tổng hợp.

Báo cáo tổng hợp cung cấp dữ liệu điều kiện kích hoạt có độ trung thực cao hơn từ thiết bị một cách nhanh hơn, ngoài dữ liệu được cung cấp cho báo cáo ở cấp sự kiện. Bạn chỉ có thể tìm hiểu dữ liệu có độ trung thực cao hơn này trong báo cáo tổng hợp, và dữ liệu này không liên kết với một điều kiện kích hoạt hoặc người dùng cụ thể. Khoá tổng hợp có kích thước tối đa 128 bit, cho phép các báo cáo tổng hợp hỗ trợ những trường hợp sử dụng báo cáo như:

• Báo cáo cho các giá trị của điều kiện kích hoạt, chẳng hạn như doanh thu
• Xử lý nhiều loại trình kích hoạt hơn

Ngoài ra, báo cáo tổng hợp sử dụng cùng một logic phân bổ ưu tiên như báo cáo cấp sự kiện, nhưng hỗ trợ nhiều lượt chuyển đổi hơn được phân bổ cho lượt nhấp hoặc lượt xem.

Thiết kế tổng thể về cách API Báo cáo phân bổ chuẩn bị và gửi báo cáo tổng hợp (được minh hoạ trong hình 2) như sau:

1. Thiết bị gửi các báo cáo tổng hợp đã mã hoá cho công nghệ quảng cáo. Trong môi trường sản xuất, công nghệ quảng cáo không thể sử dụng trực tiếp những báo cáo này.
2. Công nghệ quảng cáo sẽ gửi một loạt các báo cáo tổng hợp cho dịch vụ tổng hợp để tổng hợp.
3. Dịch vụ tổng hợp sẽ đọc một loạt các báo cáo tổng hợp, giải mã rồi tổng hợp chúng.
4. Dữ liệu tổng hợp sau cùng được gửi trở lại cho công nghệ quảng cáo trong một [báo cáo tóm tắt][53]{: .external}

Hình 2. Quy trình mà API Báo cáo phân bổ sử dụng để chuẩn bị và gửi báo cáo tổng hợp.

Báo cáo tổng hợp chứa dữ liệu sau đây liên quan đến các nguồn phân bổ:

• Đích đến: Tên gói của ứng dụng hoặc URL web eTLD+1 nơi diễn ra lượt kích hoạt.
• Ngày: Ngày xảy ra sự kiện được biểu thị bởi nguồn phân bổ.
• Phần tải: Các giá trị kích hoạt, được thu thập dưới dạng cặp giá trị/khoá đã mã hoá, dùng trong dịch vụ tổng hợp đáng tin cậy để tính toán dữ liệu tổng hợp.

Dịch vụ tổng hợp

Các dịch vụ sau đây cung cấp chức năng tổng hợp và giúp ngăn chặn hoạt động truy cập không phù hợp vào dữ liệu tổng hợp.

Những dịch vụ này do nhiều bên quản lý và được mô tả chi tiết hơn ở phần sau của trang này:

• Dịch vụ tổng hợp là dịch vụ duy nhất mà các công nghệ quảng cáo dự kiến sẽ triển khai.
• Các dịch vụ quản lý khoá và hạch toán báo cáo tổng hợp do các bên đáng tin cậy (được gọi là điều phối viên) vận hành. Những điều phối viên này khẳng định rằng mã đang chạy dịch vụ tổng hợp là mã do Google cung cấp công khai và rằng tất cả người dùng dịch vụ tổng hợp đều được áp dụng cùng một khoá và cùng các dịch vụ hạch toán báo cáo tổng hợp.

Dịch vụ tổng hợp

Trước tiên, nền tảng công nghệ quảng cáo phải triển khai một dịch vụ tổng hợp dựa trên tệp nhị phân do Google cung cấp.

Dịch vụ tổng hợp này hoạt động trong Môi trường thực thi đáng tin cậy (TEE) được lưu trữ trên đám mây. TEE mang lại các lợi ích bảo mật sau đây:

• Đảm bảo mã vận hành trong TEE là tệp nhị phân cụ thể do Google cung cấp. Trừ phi điều kiện này được đáp ứng, nếu không dịch vụ tổng hợp sẽ không truy cập được vào khoá giải mã cần thiết để vận hành.
• Tính năng này mang lại khả năng bảo mật trong quá trình chạy, cách ly quy trình đó khỏi hoạt động giám sát hoặc can thiệp từ bên ngoài.

Những lợi ích bảo mật này giúp dịch vụ tổng hợp thực hiện các hoạt động nhạy cảm một cách an toàn hơn, chẳng hạn như truy cập vào dữ liệu đã mã hoá.

Để biết thêm thông tin về những điều cần cân nhắc liên quan đến thiết kế, quy trình và tính bảo mật của dịch vụ tổng hợp, hãy xem [tài liệu về dịch vụ tổng hợp][59]{: .external} trên GitHub.

Dịch vụ quản lý chính

Dịch vụ này xác minh rằng một dịch vụ tổng hợp đang chạy phiên bản được phê duyệt của tệp nhị phân, sau đó cung cấp dịch vụ tổng hợp trong công nghệ quảng cáo cùng với khoá giải mã chính xác cho dữ liệu điều kiện kích hoạt.

Hạch toán báo cáo tổng hợp

Dịch vụ này theo dõi tần suất dịch vụ tổng hợp của công nghệ quảng cáo sử dụng một điều kiện kích hoạt cụ thể (có thể chứa nhiều khoá tổng hợp) và giới hạn quyền truy cập vào số lượng khoá giải mã phù hợp. Hãy tham khảo đề xuất thiết kế Dịch vụ tổng hợp cho API Báo cáo phân bổ để biết thông tin chi tiết.

API Báo cáo tổng hợp

API dùng để tạo dữ liệu đóng góp cho các báo cáo tổng hợp, sử dụng cùng một API cơ sở như khi đăng ký nguồn phân bổ cho các báo cáo cấp sự kiện. Các phần sau đây mô tả phần mở rộng của API.

Đăng ký dữ liệu nguồn tổng hợp

Khi API gửi yêu cầu đến URI nguồn phân bổ, công nghệ quảng cáo có thể đăng ký danh sách các khoá tổng hợp, với tên histogram_contributions, bằng cách phản hồi bằng một trường mới có tên là aggregation_keys trong tiêu đề HTTP Attribution-Reporting-Register-Source, với khoá là key_name và giá trị dưới dạng key_piece:

• (Khoá) Tên khoá: Một chuỗi cho tên của khoá. Được dùng làm khoá kết hợp để kết hợp với các khoá phía điều kiện kích hoạt nhằm tạo thành khoá cuối cùng.
• (Giá trị) Đoạn khoá: Giá trị chuỗi bit của khoá.

Khoá nhóm biểu đồ cuối cùng được xác định đầy đủ tại thời điểm kích hoạt bằng cách thực hiện hoạt động nhị phân HOẶC toán tử trên các thành phần này và các thành phần phía điều kiện kích hoạt.

Các khoá cuối cùng được hạn chế ở tối đa 128 bit; các khoá dài hơn giới hạn này bị cắt ngắn. Điều này có nghĩa là các chuỗi hệ lục phân trong JSON chỉ nên có tối đa 32 chữ số.

Tìm hiểu thêm về cấu trúc của các khoá tổng hợp và cách bạn có thể định cấu hình các khoá tổng hợp đó.

Trong ví dụ sau, một công nghệ quảng cáo sử dụng API để thu thập những thông tin dưới đây:

• Tổng số lượt chuyển đổi cấp chiến dịch
• Giá trị mua hàng tổng hợp ở cấp địa lý

// This is where the Attribution-Reporting-Register-Source object appears when
// an ad tech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Source:
…
aggregation_keys: {
  // Generates a "0x159" key piece named (low order bits of the key) for the key
  // named "campaignCounts".
  // User saw an ad from campaign 345 (out of 511).

  "campaignCounts": "0x159",
  // Generates a "0x5" key piece (low order bits of the key) for the key name "geoValue"
  // Source-side geo region = 5 (US), out of a possible ~100 regions.
  "geoValue": "0x5"
}

Đăng ký điều kiện kích hoạt tổng hợp

Quy trình đăng ký điều kiện kích hoạt gồm 2 trường bổ sung.

Trường đầu tiên được dùng để đăng ký danh sách khoá tổng hợp phía điều kiện kích hoạt. Công nghệ quảng cáo sẽ phản hồi lại bằng trường aggregatable_trigger_data trong tiêu đề HTTP Attribution-Reporting-Register-Trigger, với các trường sau đây cho từng khoá tổng hợp trong danh sách:

• Đoạn khoá: Giá trị chuỗi bit của khoá.
• Khoá nguồn: Danh sách các chuỗi có tên khoá phía nguồn phân bổ sẽ kết hợp với khoá điều kiện kích hoạt để tạo thành khoá cuối cùng.

Trường thứ hai dùng để đăng ký danh sách các giá trị sẽ đóng góp cho mỗi khoá. Công nghệ quảng cáo sẽ phản hồi lại bằng trường aggregatable_values trong tiêu đề HTTP Attribution-Reporting-Register-Trigger. Trường thứ hai dùng để đăng ký danh sách các giá trị sẽ đóng góp cho mỗi khoá, giá trị này có thể là số nguyên trong phạm vi $ [1, 2^{16}] $.

Mỗi điều kiện kích hoạt có thể đóng góp nhiều lượt cho báo cáo tổng hợp. Tổng số lượt đóng góp cho nguồn phân bổ nhất định chịu ràng buộc bởi thôn số $ L1 $. Thông số này là tổng tối đa của các giá trị phân bổ (giá trị) trên tất cả các khoá tổng hợp của một nguồn phân bổ nhất định. $ L1 $ đề cập đến độ nhạy hoặc tiêu chuẩn L1 của biểu đồ lượt đóng góp cho mỗi sự kiện nguồn. Nếu vượt quá giới hạn này, các lượt đóng góp trong tương lai sẽ lặng lẽ giảm. Đề xuất ban đầu là đặt $ L1 $ thành $ 2^{16} $ (65536).

Độ nhiễu trong dịch vụ tổng hợp sẽ được điều chỉnh theo tỷ lệ với thông số này. Do đó, bạn nên mở rộng quy mô một cách phù hợp đối với các giá trị được báo cáo cho một khoá tổng hợp nhất định, dựa trên tỷ lệ ngân sách quyền riêng tư $ L1 $ được phân bổ cho khoá đó. Cách này giúp đảm bảo các báo cáo tổng hợp duy trì độ trung thực cao nhất có thể khi áp dụng độ nhiễu. Cơ chế này có tính linh hoạt cao và có thể hỗ trợ nhiều chiến dịch tổng hợp.

Trong ví dụ sau, ngân sách quyền riêng tư được chia đều giữa campaignCounts và geoValue bằng cách chia phần đóng góp $ L1 $ cho mỗi khoá:

// This is where the Attribution-Reporting-Register-Trigger object appears
// when an ad tech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-Trigger:{
    …
    "aggregatable_trigger_data":

    [
    // Each dictionary independently adds pieces to multiple source keys.
    {
    // Conversion type purchase = 2 at a 9-bit offset, i.e. 2 << 9.
    // A 9-bit offset is needed because there are 511 possible campaigns, which
    // will take up 9 bits in the resulting key.
        "key_piece": "0x400",// Conversion type purchase = 2
        // Apply this key piece to:
        "source_keys": ["campaignCounts"]
    },
    {
    // Purchase category shirts = 21 at a 7-bit offset, i.e. 21 << 7.
    // A 7-bit offset is needed because there are ~100 regions for the geo key,
    // which will take up 7 bits of space in the resulting key.
        "key_piece": "0xA80",
        // Apply this key piece to:
        "source_keys": ["geoValue", "nonMatchingIdsListedHereAreIgnored"]
    }
    ]

    // Specify an amount of an abstract value which can be integers in [1, 2^16] to
    // contribute to each key that is attached to aggregation keys in the order that
    // they're generated.
    aggregatable_values:
    {
    // Privacy budget for each key is L1 / 2 = 2^15 (32768).
    // Conversion count was 1.
    // Scale the count to use the full budget allocated: 1 * 32768 = 32768.
        "campaignCounts": 32768,

    // Purchase price was $52.
    // Purchase values for the app range from $1 to $1,024 (integers only).
    // Scaling factor applied is 32768 / 1024 = 32.
    // For $52 purchase, scale the value by 32 ($52 * 32 = $1,664).
        "geoValue": 1664
    }
}

Ví dụ trước tạo ra các giá trị đóng góp cho biểu đồ như sau:

[
  // campaignCounts:
  {
    "key": "0x559", // = 0x159 | 0x400
    "value": 32768
  },
  // geoValue:
  {
    "key": "0xA85",  // = 0x5 | 0xA80
    "value": 1664
  }
]

Lưu ý: filters vẫn áp dụng cho các báo cáo tổng hợp, và mỗi từ điển trong aggregatable_trigger_data có thể vẫn áp dụng các bộ lọc chuyển đổi (không bắt buộc), giống như bộ lọc trình kích hoạt cho báo cáo cấp sự kiện.

Bạn có thể đảo ngược hệ số tỷ lệ để đạt được giá trị chính xác, độ nhiễu mô-đun được áp dụng:

L1 = 65536
trueCampaignCounts = campaignCounts / (L1 / 2)
trueGeoValue = geoValue / (L1 / 2) * 1024

Sự riêng tư biệt lập

Mục tiêu của API này là đặt ra một khung có thể hỗ trợ hoạt động đo lường tổng hợp sự riêng tư một cách biệt lập. Có thể đạt được điều này bằng cách thêm độ nhiễu theo tỷ lệ vào ngân sách $ L1 $, chẳng hạn như chọn độ nhiễu bằng lệnh phân phối sau đây:

\[ Laplace(\frac{L1}{ε}) \]

Tích hợp Protected Audience API và Attribution Reporting API

Việc tích hợp trên nhiều API giữa Protected Audience API và Attribution Reporting API cho phép các công nghệ quảng cáo đánh giá hiệu suất phân bổ trong số nhiều chiến thuật tái tiếp thị để hiểu rõ những loại đối tượng nào mang lại ROI cao nhất.

Thông qua việc tích hợp trên nhiều API này, các công nghệ quảng cáo có thể:

• Tạo một sơ đồ khoá-giá trị của URI cần dùng cho cả việc 1) báo cáo lượt tương tác và 2) đăng ký nguồn.
• Đưa CustomAudience vào hoạt động ánh xạ khoá phía nguồn để báo cáo tóm tắt tổng hợp (thông qua Attribution Reporting API).

Khi người dùng xem hoặc nhấp vào một quảng cáo:

• URL dùng để báo cáo những hoạt động tương tác đó bằng Protected Audience cũng sẽ dùng để đăng ký một lượt xem hoặc lượt nhấp dưới dạng nguồn đủ điều kiện thông qua Attribution Reporting API.
• Công nghệ quảng cáo có thể chọn truyền CustomAudience (hoặc các thông tin bối cảnh liên quan khác về quảng cáo, chẳng hạn như quy trình đặt quảng cáo hoặc thời lượng xem) thông qua URL đó để siêu dữ liệu này có thể truyền xuống các báo cáo tóm tắt khi công nghệ quảng cáo đang xem xét hiệu suất chiến dịch tổng hợp.

Để biết thêm thông tin về cách bật chế độ này trong Protected Audience, hãy xem phần liên quan trong [tài liệu giải thích về Protected Audience API][64].

Ví dụ về mức độ ưu tiên đăng ký, phân bổ và báo cáo

Ví dụ này cho thấy một tập hợp các lượt tương tác của người dùng và cách nguồn phân bổ do công nghệ quảng cáo xác định cũng như mức độ ưu tiên của trình kích hoạt ảnh hưởng thế nào đến các báo cáo phân bổ. Ở ví dụ này, chúng tôi giả định như bên dưới:

• Tất cả nguồn phân bổ và điều kiện kích hoạt đều được đăng ký bởi cùng một công nghệ quảng cáo, cho cùng một nhà quảng cáo.
• Tất cả nguồn phân bổ và điều kiện kích hoạt đều diễn ra trong thời gian báo cáo sự kiện đầu tiên (trong vòng 2 ngày kể từ lúc hiển thị quảng cáo đầu tiên trong ứng dụng của nhà xuất bản).

Hãy cân nhắc các trường hợp mà người dùng thực hiện như sau:

1. Người dùng thấy một quảng cáo. Công nghệ quảng cáo đăng ký nguồn phân bổ bằng API, với mức độ ưu tiên là 0 (lượt xem #1).
2. Người dùng thấy quảng cáo được đăng ký với mức độ ưu tiên là 0 (lượt xem #2).
3. Người dùng nhấp vào quảng cáo, được đăng ký với mức độ ưu tiên là 1 (lượt nhấp #1).
4. Người dùng chuyển đổi (truy cập vào trang đích) trong một ứng dụng của nhà quảng cáo. Công nghệ quảng cáo đăng ký điều kiện kích hoạt thông qua API, với mức độ ưu tiên là 0 (lượt chuyển đổi #1).
   • Khi các điều kiện kích hoạt được đăng ký, API sẽ thực hiện phân bổ trước khi tạo báo cáo.
   • Có sẵn 3 nguồn phân bổ: lượt xem #1, lượt xem #2 và lượt nhấp #1. API phân bổ điều kiện kích hoạt này cho lượt nhấp #1 vì nó có mức độ ưu tiên cao nhất và gần đây nhất.
   • Lượt xem #1 và lượt xem #2 bị loại bỏ và không còn đủ điều kiện để phân bổ trong tương lai.
5. Người dùng thêm một mặt hàng vào giỏ hàng trong ứng dụng của nhà quảng cáo, được đăng ký có mức độ ưu tiên là 1 (lượt chuyển đổi #2).
   • Lượt nhấp #1 là nguồn phân bổ duy nhất đủ điều kiện. API phân bổ điều kiện kích hoạt này để nhấp vào #1.
6. Người dùng thêm một mặt hàng vào giỏ hàng trong ứng dụng của nhà quảng cáo, được đăng ký có mức độ ưu tiên là 1 (lượt chuyển đổi #3).
   • Lượt nhấp #1 là nguồn phân bổ duy nhất đủ điều kiện. API phân bổ điều kiện kích hoạt này để nhấp vào #1.
7. Người dùng thêm một mặt hàng vào giỏ hàng trong ứng dụng của nhà quảng cáo, được đăng ký có mức độ ưu tiên là 1 (lượt chuyển đổi #4).
   • Lượt nhấp #1 là nguồn phân bổ duy nhất đủ điều kiện. API phân bổ điều kiện kích hoạt này để nhấp vào #1.
8. Người dùng mua hàng trong ứng dụng của nhà quảng cáo, được đăng ký có mức độ ưu tiên là 2 (lượt chuyển đổi #5).
   • Lượt nhấp #1 là nguồn phân bổ duy nhất đủ điều kiện. API phân bổ điều kiện kích hoạt này để nhấp vào #1.

Báo cáo cấp sự kiện có các đặc điểm sau:

• Theo mặc định, 3 trình kích hoạt đầu tiên được phân bổ cho một lượt nhấp và trình kích hoạt đầu tiên được phân bổ cho một lượt xem sẽ gửi đi sau thời gian báo cáo có thể áp dụng.
• Trong khoảng thời gian báo cáo, nếu có các điều kiện kích hoạt được đăng ký với mức độ ưu tiên cao hơn, thì các điều kiện kích hoạt đó sẽ được ưu tiên và thay thế điều kiện kích hoạt gần đây nhất.
• Trong ví dụ trước, công nghệ quảng cáo nhận được 3 báo cáo sự kiện sau khoảng thời gian báo cáo 2 ngày cho lượt chuyển đổi #2, lượt chuyển đổi #3 và lượt chuyển đổi #5.
  • Tất cả 5 điều kiện kích hoạt đều được quy cho lượt nhấp #1. Theo mặc định, API sẽ gửi báo cáo cho 3 điều kiện kích hoạt đầu tiên: lượt chuyển đổi #1, lượt chuyển đổi #2 và lượt chuyển đổi #3.
  • Tuy nhiên, mức độ ưu tiên của lượt chuyển đổi #4 (1) cao hơn lượt chuyển đổi #1 (0). Báo cáo sự kiện của lượt chuyển đổi #4 thậm chí sẽ thay thế báo cáo sự kiện của lượt chuyển đổi #1 sẽ được gửi đi.
  • Ngoài ra, mức độ ưu tiên của lượt chuyển đổi #5 (2) sẽ cao hơn bất kỳ điều kiện kích hoạt nào khác. Báo cáo sự kiện của lượt chuyển đổi #5 thay thế cho báo cáo của lượt chuyển đổi #4 sẽ được gửi đi.

Báo cáo tổng hợp có các đặc điểm sau:

• Hệ thống gửi báo cáo tổng hợp đã mã hoá đến công nghệ quảng cáo ngay sau khi báo cáo này được xử lý và vài giờ sau khi điều kiện kích hoạt được đăng ký.

  Là một công nghệ quảng cáo, bạn tạo các lô của chúng dựa trên thông tin được mã hoá trong báo cáo tổng hợp của mình. Thông tin này nằm trong trường shared_info thuộc báo cáo tổng hợp của bạn, bao gồm cả dấu thời gian và nguồn gốc báo cáo. Bạn không thể phân theo nhóm dựa trên bất kỳ thông tin mã hoá nào trong các cặp khoá-giá trị tổng hợp của mình. Một số chiến lược đơn giản bạn có thể làm theo là phân lô báo cáo theo ngày hoặc theo tuần. Mỗi lô nên chứa ít nhất 100 báo cáo.

• Công nghệ quảng cáo phụ thuộc vào thời điểm và cách thức phân lô các báo cáo tổng hợp đồng thời gửi đến dịch vụ tổng hợp.

• So với các báo cáo cấp sự kiện, báo cáo tổng hợp được mã hoá có thể phân bổ nhiều điều kiện kích hoạt hơn cho một nguồn.

• Trong ví dụ trước, 5 báo cáo tổng hợp đã được gửi đi và mỗi báo cáo cho mỗi điều kiện kích hoạt đã đăng ký.

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

Attribution Reporting API là một cách mới và khá phức tạp để đo lường mô hình phân bổ mà không cần giá trị nhận dạng giữa các ứng dụng. Do đó, chúng tôi đang hỗ trợ một cơ chế chuyển đổi để 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 (người dùng chưa chọn không sử dụng tính năng cá nhân hoá bằng mã nhận dạng cho quảng cáo và nhà xuất bản hoặc ứng dụng của nhà quảng cáo đã khai báo quyền sử dụng mã nhận dạng cho quảng cáo). Điều này đảm bảo rằng API có thể được hiểu đầy đủ trong quá trình triển khai, giúp loại bỏ lỗi và dễ dàng so sánh hiệu suất với các giải pháp thay thế dựa trên 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.

Hãy đọc hướng dẫn về báo cáo gỡ lỗi chuyển đổi để biết thông tin chi tiết về báo cáo gỡ lỗi bằng phương thức đo lường từ ứng dụng đến web và từ web đến ứng dụng.

Báo cáo gỡ lỗi phân bổ thành công

Cả hoạt động đăng ký điều kiện kích hoạt và nguồn đều chấp nhận trường debug_key 64 bit mới (có định dạng Chuỗi), mà công nghệ quảng cáo sẽ điền sẵn. source_debug_key và trigger_debug_key được truyền không thay đổi trong cả báo cáo tổng hợp và báo cáo cấp sự kiện.

Nếu một báo cáo được tạo bằng cả khoá gỡ lỗi nguồn và điều kiện kích hoạt, thì báo cáo gỡ lỗi trùng lặp sẽ được gửi với độ trễ giới hạn theo điểm cuối của .well-known/attribution-reporting/debug/report-event-attribution.

Đối với các bản phát hành DP 10 trở lên, các yêu cầu báo cáo gỡ lỗi phân bổ thành công sẽ chứa tiêu đề Phiên bản như sau: Version: 202310

Báo cáo gỡ lỗi giống với báo cáo thông thường, bao gồm cả 2 trường khoá gỡ lỗi. Khi có các khoá này ở cả 2 trường, các báo cáo thông thường có thể liên kết với luồng báo cáo gỡ lỗi riêng biệt.

• Đối với các báo cáo cấp sự kiện:
  • Các báo cáo gỡ lỗi trùng lặp được gửi với độ trễ giới hạn nên không chịu ảnh hưởng của các giới hạn về điều kiện kích hoạt có sẵn, giúp công nghệ quảng cáo hiểu được tác động của các giới hạn đó đối với báo cáo cấp sự kiện.
  • Các báo cáo cấp sự kiện liên kết với sự kiện của điều kiện kích hoạt có giá trị false (sai) sẽ không có trigger_debug_key. Điều này giúp công nghệ quảng cáo hiểu rõ hơn cách áp dụng hiện tượng nhiễu trong API.
• Đối với báo cáo tổng hợp:
  • Chúng tôi sẽ hỗ trợ một trường debug_cleartext_payload mới có chứa tải trọng đã giải mã, chỉ khi bạn đặt cả source_debug_key và trigger_debug_key.

Báo cáo gỡ lỗi chi tiết

Báo cáo gỡ lỗi chi tiết cho phép nhà phát triển theo dõi một số lỗi nhất định trong nguồn phân bổ hoặc lượt đăng ký điều kiện kích hoạt. Các báo cáo gỡ lỗi này được gửi với độ trễ giới hạn sau khi có lượt đăng ký nguồn phân bổ hoặc điều kiện kích hoạt sang mộtĐiểm cuối well-known/attribution-reporting/debug/verbose.

Đối với các bản phát hành DP 10 trở lên, các yêu cầu báo cáo gỡ lỗi phân bổ thành công sẽ chứa tiêu đề Phiên bản như sau: Version: 202310

Mỗi báo cáo chi tiết chứa các trường sau:

• Loại: lý do khiến báo cáo được tạo. Xem [danh sách đầy đủ các loại báo cáo chi tiết][67]{:.external}.
  • Nói chung, có báo cáo chi tiết về nguồn và báo cáo chi tiết về điều kiện kích hoạt.
  • Báo cáo chi tiết về nguồn phải có mã nhận dạng cho quảng cáo cho ứng dụng của nhà xuất bản. Báo cáo chi tiết về điều kiện kích hoạt phải có mã nhận dạng cho quảng cáo cho ứng dụng của nhà quảng cáo.
  • Hầu hết các báo cáo chi tiết về điều kiện kích hoạt (ngoại trừ trigger-no-matching-source) có thể bao gồm source_debug_key. Bạn chỉ có thể bao gồm mã nhận dạng cho quảng cáo nếu ứng dụng của nhà xuất bản cũng có mã này.
• Nội dung: Nội dung của báo cáo, tùy thuộc vào loại báo cáo.

Công nghệ quảng cáo cần chọn nhận các báo cáo gỡ lỗi chi tiết bằng trường từ điển debug_reporting mới trong các tiêu đề Attribution-Reporting-Register_Source và Attribution-Reporting-Register-Trigger.

• Báo cáo chi tiết nguồn chỉ yêu cầu chọn sử dụng tiêu đề của gói đăng ký nguồn.
• Các báo cáo gỡ lỗi về điều kiện kích hoạt đều chỉ yêu cầu chọn sử dụng tiêu đề của gói đăng ký điều kiện kích hoạt.

Cách sử dụng báo cáo gỡ lỗi

Nếu xảy ra một lượt chuyển đổi (theo hệ thống đo lường hiện có) và bạn nhận được báo cáo gỡ lỗi cho lượt chuyển đổi đó, thì tức là điều kiện kích hoạt đã được đăng ký thành công.

Đối với mỗi báo cáo phân bổ gỡ lỗi, hãy kiểm tra xem bạn có nhận được báo cáo phân bổ thông thường khớp với 2 khoá gỡ lỗi hay không.

Có một số lý do dẫn đến việc không có kết quả phù hợp.

Hoạt động như mong đợi:

• Các hành vi của API bảo đảm quyền riêng tư:
  • Người dùng đạt đến giới hạn tốc độ báo cáo – khiến tất cả các báo cáo tiếp theo không được gửi trong khoảng thời gian đó; hoặc một nguồn bị xoá do giới hạn về đích đến đang chờ xử lý.
  • Đối với các báo cáo cấp sự kiện: báo cáo phải được phản hồi theo cách ngẫu nhiên (độ nhiễu) và bị chặn hoặc bạn có thể nhận được báo cáo ngẫu nhiên.
  • Đối với các báo cáo cấp sự kiện: đã đạt đến giới hạn 3 báo cáo (đối với lượt nhấp) hoặc 1 báo cáo (đối với lượt xem) và các báo cáo tiếp theo không đặt mức độ ưu tiên rõ ràng hoặc mức độ ưu tiên thấp hơn các báo cáo hiện tại.
  • Đã vượt quá giới hạn đóng góp cho báo cáo tổng hợp.
• Logic kinh doanh do công nghệ quảng cáo xác định:
  • Một điều kiện kích hoạt sẽ được lọc ra thông qua bộ lọc hoặc quy tắc về mức độ ưu tiên.
• Độ trễ thời gian hoặc hoạt động tương tác với khả năng sử dụng mạng (ví dụ: người dùng tắt thiết bị trong một khoảng thời gian dài).

Nguyên nhân ngoài ý muốn:

• Vấn đề về hoạt động triển khai:
  • Tiêu đề của nguồn bị định sai cấu hình.
  • Tiêu đề của điều kiện kích hoạt bị định sai cấu hình.
  • Các vấn đề khác về cấu hình.
• Vấn đề về thiết bị hoặc mạng:
  • Lỗi do điều kiện mạng.
  • Phản hồi đăng ký nguồn hoặc điều kiện kích hoạt không tiếp cận được với ứng dụng khách.
  • Lỗi API.

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

API Báo cáo phân bổ đang trong quá trình hoàn thiện. Chúng tôi cũng sẽ khám phá các tính năng có thể xuất hiện trong tương lai, chẳng hạn như mô hình phân bổ theo lần nhấp cuối cùng và các trường hợp sử dụng về đo lường trên nhiều thiết bị.

Ngoài ra, chúng tôi muốn nhận được phản hồi của cộng đồng về một số vấn đề:

1. Có trường hợp sử dụng nào mà bạn muốn API gửi báo cáo cho lượt cài đặt đã xác minh không? Các báo cáo này sẽ được tính vào giới hạn tốc độ tương ứng của các nền tảng công nghệ quảng cáo.
2. Bạn có lường trước được những khó khăn khi truyền InputEvent từ ứng dụng sang công nghệ quảng cáo để đăng ký nguồn không?
3. Bạn có trường hợp sử dụng phân bổ đặc biệt nào cho các ứng dụng được tải sẵn hoặc các ứng dụng được cài đặt lại không?