Hộp cát về quyền riêng tư trên Bản dùng thử dành cho nhà phát triển Android đã ra mắt! Tìm hiểu cách bắt đầutiếp tục cung cấp ý kiến phản hồi.

Báo cáo phân bổ

Stay organized with collections Save and categorize content based on your preferences.

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

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, và để 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 trong tài liệu này sẽ mô tả chi tiết hơn:

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 của họ bằng cách hiển thị số lượt chuyển đổi (trình kích hoạt) và giá trị lượt chuyển đổi (trình 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á 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 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ý trình 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. API Báo cáo phân bổ so khớp trình kích hoạt với một nguồn phân bổ — phân bổ lượt chuyển đổi — và một hoặc nhiều trình kích hoạt được gửi ra ngoà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.

Đăng ký công nghệ quảng cáo

Để truy cập vào API Báo cáo phân bổ và để đảm bảo rằng cơ chế quyền riêng tư hoạt động như mong muốn, tất cả các nền tảng công nghệ quảng cáo (bao gồm cả nền tảng của Google) đều cần hoàn tất quy trình đăng ký đơn giản. Thông tin chi tiết về quy trình này vẫn đang trong quá trình phát triển. Chúng tôi hoan nghênh ý kiến phản hồi của bạn.

Quy trình đăng ký đảm bảo rằng các nền tảng công nghệ quảng cáo không nhất thiết phải tự nhân bản để thu thập thêm thông tin về các hoạt động của người dùng trên trang web và ứng dụng. Ví dụ: API Báo cáo phân bổ giới hạn hoạt động theo dõi và lượng thông tin mà một nền tảng công nghệ quảng cáo có thể xem đối với một nguồn phân bổ và trình kích hoạt nhất định. Bạn có thể xem thông tin chi tiết về các giới hạn này trong phần cách xem dữ liệu đo lường trong báo cáo phân bổ ở phần sau của tài liệu này.

Doanh nghiệp có thể đăng ký nhiều lần nếu có nhu cầu kinh doanh hợp pháp (chẳng hạn như vận hành nhiều dòng sản phẩm độc lập) và họ không kết hợp dữ liệu của nhiều lần đăng ký để bỏ qua các giới hạn về quyền riêng tư.

Trong quá trình đăng ký, các nền tảng công nghệ quảng cáo cung cấp những thông tin đại loại như sau:

  • Thông tin liên hệ và thông tin doanh nghiệp
  • URL dùng để đăng ký các nguồn phân bổ và trình kích hoạt
  • URL đăng lại dùng để nhận báo cáo cấp sự kiện và báo cáo tổng hợp
  • Các trường hợp sử dụng API Báo cáo phân bổ

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

API Báo cáo phân bổ đề cập đến lượt nhấp quảng cáo và lượt xem dưới dạng nguồn phân bổ. Để đăng ký một lượt nhấp 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 thông 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: Một DOMString mã hoá số nguyên 64 bit chưa ký. Giá trị này đại diện cho 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 quảng cáo).
  • Đích: Nguồn gốc có eTLD+1 hoặc tên gói ứng dụng trong đó xảy ra sự kiện trình 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à khoảng 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à 2 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.
  • Mức ưu tiên nguồn (không bắt buộc): Số nguyên 64 bit đã ký được dùng để chọn nguồn phân bổ nào sẽ liên kết với một trình kích hoạt nhất định, trong trường hợp có nhiều nguồn phân bổ có thể được liên kết với trình kích hoạt này.

    Khi nhận được một trình 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 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 lớn.

  • Thời lượng phân bổ cài đặt và sau cài đặt (không bắt buộc): Được dùng để xác định tính năng phân bổ cho sự kiện sau cài đặt, được mô tả trong phần sau của tài liệu này.

  • Lọc dữ liệu (không bắt buộc): Dùng để lọc một số trình kích hoạt có chọn lọc, bỏ qua hiệu quả của chúng. Để biết thêm thông tin, vui lòng xem mục các bộ lọc trình 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ý yêu cầu.

Tài liệu hướng dẫn dành cho nhà phát triển có các ví dụ về cách chấp nhận đă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-Redirects: https://adtechpartner1.example?their_ad_click_id=567,
    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-Redirects. Trong ví dụ này, hai 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"
    }
    

Ba 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ý trình 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ý trình 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 trình 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 trình 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-Event-Trigger, đại diện cho thông tin trên một hoặc nhiều trình 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 trình kích hoạt: Dữ liệu để xác định sự kiện của trình kích hoạt (3 bit cho lượt nhấp, 1 bit cho lượt xem)
  • Mức ưu tiên của trình kích hoạt (không bắt buộc): Số nguyên 64 bit đã ký, đại diện cho 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ổ Để 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 ví dụ về mức độ ưu tiên.
  • Khoá loại bỏ trùng lặp (không bắt buộc): Số nguyên 64 bit đã ký được dùng để xác định các trường hợp trong đó cùng một trình 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ổ
  • Khoá tổng hợp (không bắt buộc): Một 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 báo cáo phân bổ (không bắt buộc): Bộ lọc này dùng để lọc trình kích hoạt hoặc kích hoạt dữ liệu một cách có chọn lọc. Để biết thêm thông tin, vui lòng xem mục các bộ lọc trình 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 trình kích hoạt bằng lệnh chuyển hướng trong trường Attribution-Reporting-Redirects 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 trình 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 trình 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 dành cho nhà phát triển có các ví dụ về cách chấp nhận đăng ký trình 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ý trình kích hoạt bằng URI mà họ đã đăng ký:

    triggerAttribution(
        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-Event-Trigger: {
        "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-Redirects: https://adtechpartner.example?app_install=567
    
  4. API gửi yêu cầu cho từng URL được chỉ định trong Attribution-Reporting-Redirects. Trong ví dụ này, chỉ có một URL được chỉ định, do đó, API gửi yêu cầu cho 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-Event-Trigger: {
        "trigger_data": "5566",
        "priority": "3",
        "deduplication_key": "3344"
    }
    

    Hai trình 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 trình 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 để khớp một trình kích hoạt (lượt chuyển đổi) với một nguồn phân bổ.

Các tham số ưu tiên cung cấp phương thức để tuỳ chỉnh phân bổ của trình kích hoạt cho các nguồn:

  • Bạn có thể phân bổ trình 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à 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 tài liệu 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 trình kích hoạt. Nếu có nhiều nguồn phân bổ có cùng mức ưu tiên, API sẽ chọn nguồn phân bổ được đăng ký gần 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 được phân bổ trình kích hoạt trong tương lai.

Bộ lọc trình kích hoạt

Việc đăng ký nguồn và trình kích hoạt bao gồm chức năng bổ sung không bắt buộc để thực hiện những việc sau:

  • Lọc một số trình kích hoạt có chọn lọc, bỏ qua chúng một cách hiệu quả.
  • Chọn dữ liệu 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 trình kích hoạt khỏi các báo cáo cấp sự kiện.

Để chọn lọc trình 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à trình kích hoạt. Nếu cùng một khoá được chỉ định cho cả nguồn lẫn trình kích hoạt, thì trình kích hoạt sẽ bị bỏ qua nếu giao lộ 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á lọc trình kích hoạt nào khớp với product, thì các bộ lọc sẽ bị bỏ qua.

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ý trình kích hoạt, trigger_data có thể được đặt làm một giá trị cho "source_type": ["navigation"] và dưới dạng giá trị khác cho "source_type": ["event"].

Trình 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 là đúng:

  • Bạn chưa chỉ định trigger_data nào.
  • Nguồn và trình kích hoạt chỉ định cùng một bộ lọc, nhưng các giá trị không khớp. Lưu ý trong các trường hợp này, trình 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 trình 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ừ 2 đế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, nơi 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-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.
  • API Báo cáo phân bổ 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 trình 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.

    Chúng tôi đang tìm cách hỗ trợ các trường hợp sử dụng mà người dùng gỡ cài đặt, sau đó cài đặt lại ứng dụng.

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ả các nguồn và trình 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.

Event (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 ghi nhận 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à trình 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 được đăng ký bởi công nghệ quảng cáo. Trong 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_windowpost_install_exclusivity_window dưới dạng Lượt nhấp 1
Trình kích hoạt 2 (Cài đặt bài đăng) 5 Trình kích hoạt thứ hai được đăng ký bởi công nghệ quảng cáo. Trong ví dụ này, nó đại diện cho một lượt chuyển đổi sau 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 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 được các công nghệ quảng cáo đăng ký và không được gửi trong báo cáo. Chúng không được tính vào giới hạn tốc độ của công nghệ quảng cáo. Số lượt cài đặt đã xác minh chỉ dành để 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, trình kích hoạt 1 và trình kích hoạt 2 lần lượt đại diện cho lượt chuyển đổi mở lần đầu và lượt chuyển đổi sau cài đặt. Tuy nhiên, công nghệ quảng cáo có thể đăng ký bất kỳ loại trình kích hoạt nào. Nói cách khác, trình kích hoạt đầu tiên không nhất thiết phải là lần mở đầu tiên.
  • Nếu có nhiều trình 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 tốc độ.
    • 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ỡ sau đó cài đặt lại, thì lượt cài đặt lại được tính là một lượt cài đặt đã xác minh mới.
  • Trong trường hợp lượt nhấp 1 là một sự kiện lượt xem, thì cả trình kích hoạt "mở lần đầu" và trình 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 trình 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 hai trình 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.

Mọi cách kết hợp đường dẫn đến trình kích hoạt dựa trên ứng dụng và dựa trên web đều được hỗ trợ

API Báo cáo phân bổ cho phép phân bổ các đường dẫn sau đây của trình kích hoạt trên một thiết bị 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ự như 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 Android API để 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 trình 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 trình kích hoạt "cài đặt ứng dụng", một hoặc nhiều trình kích hoạt "thêm vào giỏ hàng" và một trình kích hoạt "mua hàng". Mỗi trình 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, được mô tả ở phần sau của tài liệu này.

Có giới hạn về số trình kích hoạt có thể phân bổ cho một nguồn phân bổ; để biết thông tin chi tiết, hãy đọc về cách xem dữ liệu đo lường trong báo cáo phân bổ ở phần sau của tài liệu này. Trong trường hợp có nhiều trình kích hoạt vượt quá các giới hạn này, bạn nên giới thiệu logic ưu tiên để khai thác tối đa trình 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 trình kích hoạt "mua hàng" hơn là trình 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 trên trình kích hoạt, và trình 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.

Cho phép nhiều công nghệ quảng cáo đăng ký các trình 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 trình 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à trình kích hoạt để nhận đăng lại từ API, còn việc phân bổ được thực hiện giữa các nguồn phân bổ và trình 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 để thực hiện 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ư sau:

  • 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-Redirects 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 của 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 của công nghệ quảng cáo của đối tác trong trường Attribution-Reporting-Redirects, và các công nghệ quảng cáo của đối tác không thể chỉ định trường Attribution-Reporting-Redirects 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().

Trình kích hoạt

Để đăng ký trình 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-Redirects bổ sung hoặc mỗi adtech có thể gọi phương thức registerTrigger().

Khi một 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 của trình kích hoạt, nên sử 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ý trình kích hoạt và đặt URL trong trường chuyển hướng của lệnh gọi 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, các trình kích hoạt trùng lặp có thể được báo cáo ngược lại cho từng công nghệ quảng cáo dưới dạng một trình kích hoạt duy nhất.

Xử lý các trình 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 trình kích hoạt nhiều lần bằng API. Các trường hợp này bao gồm:

  • Người dùng thực hiện cùng một thao tác (trình 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 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 hai đối tác đo lường là MMP #1 và MMP #2. Cả hai MMP đều chuyển hướng đến adtech #3. Khi một sự kiện kích hoạt xảy ra, cả hai MMP đều đăng ký trình kích hoạt đó bằng API Báo cáo phân bổ. Sau đó, adtech #3 nhận được hai 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 trình 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 của trình kích hoạt trùng lặp, nhằm giảm khả năng vượt quá giới hạn tốc độ được áp dụng cho các báo cáo ở cấp sự kiện. Bạn nên dùng một 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ẽ chuyể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-Redirects.

Các công nghệ quảng cáo có thể chọn chỉ đăng ký trình 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 trình kích hoạt hoặc tất cả các trình kích hoạt. Các công nghệ quảng cáo có thể chỉ định deduplication_key khi đăng ký các trình kích hoạt trùng lặp.

Nếu một công nghệ quảng cáo đăng ký nhiều trình kích hoạt có cùng một khoá loại bỏ trùng lặp và nguồn được phân bổ, thì chỉ có trình kích hoạt đã đăng ký đầu tiên được gửi trong báo cáo cấp sự kiện. Những trình 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 thoả thuận thống nhất về các loại trình 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, thì lựa chọn thay thế sẽ được sử dụng. Tất cả cá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 trình 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ý trình 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-Redirects, 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 trình 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 trình 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 hai nền tảng công nghệ quảng cáo phân phát (Adtech A (Công nghệ quảng cáo A) và Adtech B (Công nghệ quảng cáo B)) và một đối tác đo lường (MMP).

Để bắt đầu, từng Adtech A, Adtech B và MMP phải hoàn tất đăng ký để có thể sử dụng API Báo cáo phân bổ.

Danh sách sau đây cung cấp một loạt hành động giả định mà mỗi người dùng sẽ xuất hiện cách nhau một ngày và cách API báo cáo phân bổ xử lý những hành động đó đối với Adtech A, Adtech B và MMP:

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

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

Adtech A cũng bao gồm URI của MMP trong tiêu đề Attribution-Reporting-Redirects. API đưa ra yêu cầu tới URI của MMP và lượt nhấp đó được đăng ký với siêu dữ liệu từ phản hồi của máy chủ của MMP.

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

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

Giống như Adtech A, Adtech B cũng đưa URI MMP vào tiêu đề Attribution-Reporting-Redirects. API đưa ra yêu cầu tới URI của MMP và lượt nhấp đó được đăng ký với siêu dữ liệu từ phản hồi của máy chủ của MMP.

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

API phản hồi giống như hoạt động vào Ngày 1, ngoại trừ việc một chế độ xem được đăng ký cho Adtech A và MMP.

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

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

MMP cũng bao gồm các URI cho Adtech A và Adtech B trong tiêu đề Attribution-Reporting-Redirects. API gửi yêu cầu tới máy chủ của Adtech A và Adtech B, sau đó lượt chuyển đổi được đăng ký theo cách phù hợp với siêu dữ liệu 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:

  • Adtech A đặt mức độ ưu tiên của các lần nhấp cao hơn các chế độ xem và do đó, nhận được lượt cài đặt được tính cho lượt nhấp vào Ngày 1.
  • Adtech 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 các lượt nhấp cao hơn số lượt xem và nhận được lượt cài đặt của 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.

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 tài liệu 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 trình kích hoạt có độ chân 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 trình 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.

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

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

Sau khi trình 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 adtech (công nghệ quảng cáo) trong một số khoả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 tài liệu 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ề trình kích hoạt. Dữ liệu trình kích hoạt ở cấp sự kiện được giới hạn ở 3 bit dữ liệu trình kích hoạt đối với lượt nhấp — điều này nghĩa là một trình kích hoạt có thể được chỉ định 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 trình kích hoạt có độ chân 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, chẳng hạn 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 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 trình kích hoạt: 1 hoặc 3 bit dữ liệu trình kích hoạt có độ chân thực thấp, tuỳ theo loại nguồn phân bổ

Cơ chế bảo vệ quyền riêng tư áp dụng cho tất cả các báo cáo

Giới hạn về số lượng công nghệ quảng cáo trên mỗi nguồn phân bổ

Có giới hạn về số lượng công nghệ quảng cáo có thể liên kết với một nguồn phân bổ, 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}.
  • 10 công nghệ quảng cáo có trình kích hoạt được phân bổ cho mỗi {nguồn ứng dụng, ứng dụng đích, trong 30 ngày}.

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

Thời gian chờ và giới hạn tố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 trình kích hoạt được phân bổ cho mỗi {ứng dụng nguồn, ứng dụng đích, trong 30 ngày}.

Số lượng các đí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 giới hạn mỗi công nghệ quảng cáo ở mức 100 đích riêng biệt cho mỗi nguồn.

Cơ chế bảo vệ 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 trình kích hoạt

API này cung cấp 1 bit đối với trình kích hoạt lượt xem hết và 3 bit đối với trình 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 trình 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 $ p $ mà nguồn phân bổ này được đăng ký như bình thường, và với xác suất $ 1-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ả mạo).

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:

\[ 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 tiến trình tính toán và có thể thay đổi dựa trên phản hồi.

Giới hạn về các trình kích hoạt hiện có (lượt chuyển đổi)

Có giới hạn về số lượng trình kích hoạt trên mỗi nguồn phân bổ, với đề xuất hiện tại như sau:

  • 1-2 trình kích hoạt cho nguồn phân bổ xem quảng cáo
  • 3 trình kích hoạt cho nguồn phân bổ nhấp vào quảng cáo

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

Khoảng thời gian cụ thể để gửi báo cáo

Các báo cáo về nguồn phân bổ lượt xem quảng cáo được gửi 1 giờ 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 2 ngày hoặc nhiều hơn 30 ngày.

Các báo cáo cho nguồn phân bổ lượt nhấp quảng cáo không được định cấu hình và gửi trướ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 gian hết 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 thời hạn (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 lượt kích hoạt đã diễn ra kể từ thời gian báo cáo trước đó và gửi báo cáo theo lịch. API hỗ trợ các khoảng thời gian báo cáo sau đây:

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

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

Báo cáo tổng hợp cung cấp dữ liệu về trình kích hoạt có độ trung thực cao 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 trình 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 và khoá này cho phép các báo cáo tổng hợp hỗ trợ hoạt động báo cáo các trường hợp sử dụng, chẳng hạn như sau:

  • Báo cáo cho các giá trị của trình 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 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 phân bổ, như 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 adtech (công nghệ quảng cao). 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 các 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 cuối 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
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ổ:

  • Nguồn: Tên gói của ứng dụng hoặc URL web eTLD+1 nơi quảng cáo được phân phát.
  • Đí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á, được 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 các bên khác nhau quản lý. Điều này được mô tả chi tiết hơn ở phần sau của tài liệu 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à ngân sách quyền riêng tư được chạy bởi các bên đáng tin cậy gọi là người xác minh. Những người xác minh 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à tất cả người dùng dịch vụ tổng hợp đều đã áp dụng cùng các dịch vụ ngân sách và khoá.
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:

  • Đảm bảo mã vận hành trong TEE là tệp nhị phân cụ thể do Google cung cấp. Trừ khi điều kiện này được đáp ứng, nếu không dịch vụ tổng hợp 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 làm việc và bảo mật của dịch vụ tổng hợp, hãy tham khảo tài liệu về dịch vụ tổng hợp trên GitHub.

Dịch vụ quản lý khoá

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 adtech (công nghệ quảng cáo) bằng khoá giải mã chính xác cho dữ liệu của trình kích hoạt.

Dịch vụ ngân sách quyền riêng tư

Dịch vụ này theo dõi tần suất một dịch vụ tổng hợp của adtech (công nghệ quảng cáo) truy cập vào một trình kích hoạt cụ thể — trình kích hoạt này có thể chứa nhiều khoá tổng hợp — và giới hạn quyền truy cập vào số khoá giải mã phù hợp. Mỗi trình kích hoạt được phép giải mã một lần.

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ổ, adtech (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 tiêu đề HTTP mới Attribution-Reporting-Register-Aggregate-Source, với các trường sau đây cho từng khoá tổng hợp trong danh sách:

  • Mã nhận dạng sự kiện nguồn: 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 trình kích hoạt nhằm tạo thành khoá cuối cùng.
  • Đoạn khoá: Giá trị bitstring 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 trong trình 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 hex trong JSON chỉ nên có tối đa 32 chữ số.

Trong ví dụ sau, một công nghệ quảng cáo sử dụng API để kết nối những giá trị sau:

  • 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 adtech registers an attribution source.

// Attribution source metadata specifying histogram contributions in aggregate report.
Attribution-Reporting-Register-Aggregatable-Source:
[{
// Generates a "0x159" key piece named (low order bits of the key) for the key
// named "campaignCounts".
  "id": "campaignCounts",
// User saw an ad from campaign 345 (out of 511).
  "key_piece": "0x159",
},
{
// Generates a "0x5" key piece (low order bits of the key) for the key named "geoValue"
  "id": "geoValue",
// Source-side geo region = 5 (US), out of a possible ~100 regions.
  "key_piece": "0x5",
}]

Đăng ký trình kích hoạt tổng hợp

Quy trình đăng ký trình kích hoạt gồm 2 tiêu đề bổ sung.

Tiêu đề đầu tiên được dùng để đăng ký danh sách khoá tổng hợp phía trình kích hoạt. Công nghệ quảng cáo sẽ phản hồi lại bằng tiêu đề HTTP Attribution-Reporting-Register-Aggregatable-Trigger-Data, 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ị bitstring của khoá.
  • Khoá nguồn: Danh sách các chuỗi có tên của khoá phía nguồn phân bổ sẽ kết hợp với khoá trình kích hoạt để tạo thành khoá cuối cùng.

Tiêu đề thứ hai được dùng để đăng ký danh sách các giá trị đóng góp vào từng khoá. Công nghệ quảng cáo sẽ phản hồi lại bằng tiêu đề HTTP Attribution-Reporting-Register-Aggregatable-Values.

Tiêu đề 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}] $. Công nghệ quảng cáo sẽ phản hồi với tiêu đề HTTP Attribution-Reporting-Register-Aggregatable-Values.

Mỗi trình 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 $. Tham 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 đó, nên mở rộng quy mô một cách phù hợp cho 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-Event-Trigger object appears
// when an adtech registers a conversion trigger.

// Specify a list of dictionaries that generates aggregation keys.
Attribution-Reporting-Register-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.
Attribution-Reporting-Register-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 biểu đồ như sau:

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

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:

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

Ví dụ về ư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ả các nguồn phân bổ và trình 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ả các nguồn phân bổ và trình 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à phát hành).

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ý một trình 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 trình 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ổ trình 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ổ trình 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ổ trình 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ổ trình 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ổ trình 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 trình kích hoạt được đăng ký với mức độ ưu tiên cao hơn, thì các trình kích hoạt đó sẽ được ưu tiên và thay thế trình 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 trình 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 trình 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 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ỳ trình 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 trình 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à cách nhóm các báo cáo hằng ngày hoặc hằng 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 nhóm 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 trình 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 trình kích hoạt đã đăng ký.

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 tiềm ẩ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 đo lường trên 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. Chúng tôi dự định hỗ trợ nhiều công nghệ quảng cáo đăng ký các nguồn phân bổ và trình kích hoạt để bật tính năng đo lường của bên thứ ba. Với đề xuất hiện tại của chúng tôi, chỉ công nghệ quảng cáo khởi đầu lệnh gọi API mới có thể chỉ định danh sách công nghệ quảng cáo bên thứ ba. Để đơn giản hoá thiết kế API, chúng tôi có thể cho phép các công nghệ quảng cáo tạo chuỗi lệnh chuyển hướng bằng cách chỉ định công nghệ quảng cáo tiếp theo.
  2. Để ngăn các báo cáo cấp sự kiện và tổng hợp trùng lặp cho cùng một trình kích hoạt, với những trường hợp công nghệ quảng cáo đăng ký cùng một trình kích hoạt nhiều lần, bạn nên sử dụng khoá loại bỏ trùng lặp. Điều này có thể xảy ra nếu một nền tảng công nghệ quảng cáo bắt đầu lệnh gọi API để đăng ký trình kích hoạt đồng thời còn được đưa vào đường dẫn chuyển hướng của một công nghệ quảng cáo khác đăng ký trình kích hoạt đó. Các ứng dụng cần truyền khoá loại bỏ trùng lặp này cho tất cả các công nghệ quảng cáo mà họ đang sử dụng, hoặc các công nghệ quảng cáo đó cần được điều chỉnh cho phù hợp với thuật ngữ loại chuyển đổi. Chúng tôi tự hỏi liệu điều đó có khả thi không.
  3. Đối với việc đăng ký nguồn phân bổ, chúng tôi đang đánh giá xem liệuthiết kế đề xuất cho bên thứ ba và chuyển hướng có khả thi hay không, bao gồm cả mạng tự phân bổ. Cụ thể, chúng tôi muốn biết liệu bạn có cần minh bạch để xem mọi người trong đường dẫn chuyển hướng hay không.
  4. Khi đăng ký nguồn phân bổ, các công nghệ quảng cáo chỉ có thể chỉ định một đích đến của ứng dụng. Chúng tôi tự hỏi liệu điều đó có hiệu quả cho các trường hợp sử dụng của bạn hay không.
  5. Khi đăng ký một nguồn phân bổ, bạn có thể cài đặt thời hạn, tương đương với giai đoạn xem lại. Thời lượng tối thiểu được chấp nhận là 2 ngày kể từ khi nguồn phân bổ xuất hiện. Chúng tôi tự hỏi liệu có trường hợp sử dụng nào khiến quy trình làm việc này bị lỗi hay không.
  6. Chúng tôi tự hỏi liệu 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 hay 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.