Tín hiệu ứng dụng được bảo vệ để hỗ trợ các quảng cáo cài đặt ứng dụng phù hợp

Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Đề xuất này phải tuân theo quy trình đăng ký và chứng thực Hộp cát về quyền riêng tư. Để biết thêm thông tin về chứng thực, vui lòng tham khảo đường liên kết chứng thực được cung cấp. Các bản cập nhật trong tương lai đối với đề xuất này sẽ mô tả các yêu cầu để có quyền truy cập vào hệ thống này.

Quảng cáo cài đặt ứng dụng dành cho thiết bị di động (còn gọi là quảng cáo thu nạp người dùng) là một loại quảng cáo trên thiết bị di động được thiết kế để khuyến khích người dùng tải một ứng dụng di động xuống. Những quảng cáo này thường được phân phát cho người dùng dựa trên mối quan tâm và thông tin nhân khẩu học của họ. Chúng cũng thường xuất hiện trong các ứng dụng dành cho thiết bị di động khác, chẳng hạn như ứng dụng trò chơi, ứng dụng mạng xã hội và ứng dụng tin tức. Khi người dùng nhấp vào quảng cáo cài đặt ứng dụng, họ sẽ được đưa trực tiếp đến cửa hàng ứng dụng để tải ứng dụng xuống.

Ví dụ: một nhà quảng cáo đang cố gắng tăng số lượt cài đặt mới cho một ứng dụng giao đồ ăn mới trên thiết bị di động ở Hoa Kỳ có thể nhắm mục tiêu các quảng cáo của họ đến những người dùng có vị trí ở Hoa Kỳ và trước đây đã tương tác với các ứng dụng giao đồ ăn khác.

Việc này thường được triển khai bằng cách đưa tín hiệu bối cảnh, tín hiệu của bên thứ nhất và tín hiệu của bên thứ ba vào giữa các công nghệ quảng cáo để tạo hồ sơ người dùng dựa trên Mã nhận dạng cho quảng cáo. Các mô hình học máy trong công nghệ quảng cáo dùng thông tin này làm dữ liệu đầu vào để chọn quảng cáo phù hợp với người dùng và có nhiều khả năng dẫn đến một lượt chuyển đổi nhất.

Các API sau đây được đề xuất để hỗ trợ các quảng cáo cài đặt ứng dụng hiệu quả nhằm cải thiện quyền riêng tư của người dùng bằng cách 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:

1. Protected App Signals API: API này tập trung vào việc lưu trữ và tạo các tính năng do công nghệ quảng cáo thiết kế để thể hiện mối quan tâm tiềm ẩn của người dùng. Công nghệ quảng cáo lưu trữ các tín hiệu sự kiện do tự xác định cho mỗi ứng dụng, chẳng hạn như lượt cài đặt ứng dụng, lượt mở lần đầu, hành động của người dùng (cấp trong trò chơi, thành tích), hoạt động mua hàng hoặc thời gian trong ứng dụng. Các tín hiệu được ghi và lưu trữ trên thiết bị để ngăn chặn rò rỉ dữ liệu và chỉ được cung cấp cho logic công nghệ quảng cáo đã lưu trữ tín hiệu nhất định trong Phiên đấu giá được bảo vệ đang chạy trong môi trường an toàn.
2. Ad Selection API (API lựa chọn quảng cáo): API này cung cấp một API để định cấu hình và thực thi Phiên đấu giá được bảo vệ chạy trong một Môi trường thực thi đáng tin cậy (TEE), trong đó các công nghệ quảng cáo truy xuất đề xuất quảng cáo, chạy quy trình suy luận, tính toán giá thầu và tính điểm để chọn quảng cáo "thắng thầu" bằng cả Protected App Signals và thông tin theo bối cảnh theo thời gian thực do nhà xuất bản cung cấp.

Dưới đây là thông tin tổng quan cấp cao về cách hoạt động của Protected App Signals để hỗ trợ các quảng cáo cài đặt ứng dụng có liên quan. Các phần sau của tài liệu này cung cấp thêm thông tin chi tiết về từng bước một.

• Tuyển chọn tín hiệu: Khi người dùng sử dụng các ứng dụng di động, công nghệ quảng cáo sẽ tuyển chọn các tín hiệu bằng cách lưu trữ các sự kiện ứng dụng do công nghệ quảng cáo xác định để phân phát quảng cáo phù hợp bằng Protected App Signals API của chúng tôi. Các sự kiện này được lưu trữ trong bộ nhớ được bảo vệ trên thiết bị, tương tự như Đối tượng tuỳ chỉnh, đồng thời được mã hoá trước khi gửi ra khỏi thiết bị. Do đó, chỉ các dịch vụ Đặt giá thầu và Phiên đấu giá chạy trong Môi trường thực thi đáng tin cậy có quyền kiểm soát bảo mật và quyền riêng tư thích hợp mới có thể giải mã các sự kiện này để đặt giá thầu và tính điểm quảng cáo.
• Mã hoá tín hiệu: Tín hiệu được chuẩn bị theo tần suất dự kiến bằng logic công nghệ quảng cáo tuỳ chỉnh. Công việc trong nền Android thực thi logic này để thực hiện quá trình mã hoá trên thiết bị nhằm tạo ra tải trọng Protected App Signals mà sau này có thể được dùng theo thời gian thực để lựa chọn quảng cáo trong Phiên đấu giá được bảo vệ của chúng tôi. Tải trọng được lưu trữ an toàn trên thiết bị cho đến khi được gửi đến một phiên đấu giá.
• Lựa chọn quảng cáo: Để chọn các quảng cáo phù hợp cho người dùng, các SDK của người bán gửi một tải trọng đã mã hoá của Protected App Signals và định cấu hình Phiên đấu giá được bảo vệ. Trong phiên đấu giá, logic tuỳ chỉnh của người mua chuẩn bị Protected App Signals cùng với dữ liệu bối cảnh do nhà xuất bản cung cấp (dữ liệu thường được chia sẻ trong một yêu cầu quảng cáo RTB mở) để thiết kế các tính năng dành cho lựa chọn quảng cáo (truy xuất quảng cáo, suy luận và tạo giá thầu). Tương tự như Protected Audience, người mua sẽ gửi quảng cáo cho người bán để được tính điểm cuối cùng trong một Phiên đấu giá được bảo vệ.
  • Truy xuất quảng cáo: Người mua sẽ dùng Protected App Signals và dữ liệu theo bối cảnh do nhà xuất bản cung cấp để thiết kế các tính năng phù hợp với các mối quan tâm của người dùng. Những tính năng này được dùng để so khớp những quảng cáo đáp ứng tiêu chí nhắm mục tiêu. Các quảng cáo không nằm trong phạm vi ngân sách sẽ được lọc ra. Sau đó, k quảng cáo hàng đầu sẽ được chọn để đặt giá thầu.
  • Đặt giá thầu: Logic đặt giá thầu tuỳ chỉnh của những người mua sẽ chuẩn bị dữ liệu theo bối cảnh do nhà xuất bản cung cấp và Protected App Signals để thiết kế các tính năng được dùng làm dữ liệu đầu vào cho các mô hình học máy của người mua để suy luận và đặt giá thầu cho quảng cáo đề xuất trong những ranh giới đáng tin cậy giúp bảo đảm quyền riêng tư. Sau đó, những người mua sẽ trả lại quảng cáo họ đã chọn cho người bán.
  • Tính điểm của người bán: Logic tính điểm tuỳ chỉnh của người bán sẽ tính điểm các quảng cáo do Người mua tham gia gửi và chọn một quảng cáo giành chiến thắng để gửi lại ứng dụng cho mục đích hiển thị.
• Báo cáo: Những người tham gia phiên đấu giá nhận được các báo cáo thắng và thua phù hợp. Chúng tôi đang tìm hiểu các cơ chế bảo đảm quyền riêng tư để đưa dữ liệu liên quan đến việc huấn luyện mô hình vào báo cáo giành chiến thắng.

Lịch trình

Sắp xếp Protected App Signals

Tín hiệu là thông tin thể hiện nhiều hoạt động tương tác của người dùng trong một ứng dụng được công nghệ quảng cáo xác định là hữu ích cho việc phân phát các quảng cáo phù hợp. Ứng dụng hoặc SDK tích hợp có thể lưu trữ hoặc xoá Protected App Signals do các công nghệ quảng cáo xác định dựa trên hoạt động của người dùng, chẳng hạn như số lượt mở ứng dụng, thành tích, hoạt động mua hàng hoặc thời gian trong ứng dụng. Protected App Signals được lưu trữ an toàn trên thiết bị và được mã hoá trước khi gửi ra khỏi thiết bị. Do đó, chỉ các dịch vụ Đặt giá thầu và Phiên đấu giá chạy trong Môi trường thực thi đáng tin cậy có khả năng kiểm soát quyền riêng tư và bảo mật thích hợp mới có thể giải mã tín hiệu này để đặt giá thầu và tính điểm quảng cáo. Tương tự như Custom Audience API, các ứng dụng hoặc SDK không thể đọc hoặc kiểm tra các tín hiệu được lưu trữ trên thiết bị; không có API để đọc giá trị tín hiệu và các API được thiết kế để tránh làm rò rỉ sự hiện diện của tín hiệu. Logic tuỳ chỉnh của công nghệ quảng cáo đã bảo vệ quyền truy cập vào các tín hiệu do chúng tạo ra để thiết kế những tính năng làm cơ sở cho việc lựa chọn quảng cáo trong một Phiên đấu giá được bảo vệ.

Protected App Signals API

Protected App Signals API hỗ trợ việc quản lý các tín hiệu bằng cơ chế uỷ quyền tương tự như cơ chế dùng cho đối tượng tuỳ chỉnh. Protected App Signals API giúp lưu trữ tín hiệu dưới dạng một giá trị vô hướng duy nhất hoặc dưới dạng chuỗi thời gian. Các tín hiệu chuỗi thời gian có thể được dùng để lưu trữ các thông tin như thời lượng phiên của người dùng. Các tín hiệu chuỗi thời gian cung cấp tiện ích để thực thi một độ dài nhất định bằng cách sử dụng quy tắc vào trước loại trước. Loại dữ liệu của tín hiệu vô hướng hoặc mỗi phần tử của tín hiệu chuỗi thời gian là một mảng byte. Mỗi giá trị được bổ sung chi tiết bằng tên gói của ứng dụng lưu trữ tín hiệu và dấu thời gian tạo của lệnh gọi API tín hiệu cửa hàng. Thông tin bổ sung này có sẵn trong JavaScript mã hoá tín hiệu. Ví dụ này cho thấy cấu trúc của các tín hiệu do một công nghệ quảng cáo nhất định sở hữu:

Ví dụ này minh hoạ tín hiệu vô hướng và tín hiệu chuỗi thời gian được liên kết với adtech1.com:

• Một tín hiệu vô hướng có khoá giá trị base64 là "A1c" và giá trị "c12Z". Kho tín hiệu đã được com.google.android.game_app kích hoạt vào ngày 1 tháng 6 năm 2023.
• Danh sách các tín hiệu có khoá "dDE" do 2 ứng dụng khác nhau tạo ra.

Các công nghệ quảng cáo được phân bổ một lượng không gian nhất định để lưu trữ các tín hiệu trên thiết bị. Các tín hiệu sẽ có một TTL tối đa và giá trị này sẽ được xác định sau.

Protected App Signals sẽ bị xoá khỏi bộ nhớ nếu ứng dụng đang tạo bị gỡ cài đặt, chặn không cho sử dụng Protected App Signals API hoặc nếu dữ liệu ứng dụng bị người dùng xoá.

Protected App Signals API bao gồm các phần sau:

• API Java và JavaScript để thêm, cập nhật hoặc xoá các tín hiệu.
• API JavaScript để xử lý các tín hiệu được duy trì nhằm chuẩn bị cho các kỹ thuật trích xuất tính chất khác theo thời gian thực trong Phiên đấu giá được bảo vệ chạy trong một Môi trường thực thi đáng tin cậy (TEE).

Thêm, cập nhật hoặc xoá các tín hiệu

Công nghệ quảng cáo có thể thêm, cập nhật hoặc xoá các tín hiệu bằng API fetchSignalUpdates(). API này hỗ trợ tính năng uỷ quyền tương tự như tính năng uỷ quyền đối tượng tuỳ chỉnh của Protected Audience.

Để thêm một tín hiệu, các công nghệ quảng cáo của người mua không xuất hiện trên SDK trong các ứng dụng cần phải cộng tác với các công nghệ quảng cáo xuất hiện trên thiết bị, chẳng hạn như các đối tác đo lường trên thiết bị di động (MMP) và nền tảng bên cung (SSP). Protected App Signals API hướng đến việc hỗ trợ các công nghệ quảng cáo này bằng cách cung cấp các giải pháp linh hoạt để quản lý Protected App Signal thông qua việc cho phép phương thức gọi trên thiết bị gọi lệnh tạo Protected App Signal thay cho người mua. Quá trình này được gọi là uỷ quyền và tận dụng API fetchSignalUpdates(). fetchSignalUpdates() lấy một URI và truy xuất danh sách thông tin cập nhật tín hiệu. Để minh hoạ, fetchSignalUpdates() sẽ đưa ra yêu cầu GET đến URI nhất định để truy xuất danh sách thông tin cập nhật áp dụng cho bộ nhớ tín hiệu cục bộ. Điểm cuối URL do người mua sở hữu sẽ phản hồi bằng danh sách các lệnh JSON.

Các lệnh JSON được hỗ trợ là:

• put: chèn hoặc ghi đè giá trị vô hướng cho khoá đã cho.
• put_if_not_present: chèn giá trị vô hướng cho khoá đã cho nếu chưa có giá trị nào được lưu trữ. Tuỳ chọn này có thể hữu ích, chẳng hạn như để đặt mã thử nghiệm cho người dùng nhất định và tránh ghi đè mã đó nếu một ứng dụng khác đã đặt mã đó.
• append: thêm phần tử vào chuỗi thời gian liên kết với khoá đã cho. Tham số maxSignals chỉ định số lượng tín hiệu tối đa trong chuỗi thời gian. Nếu vượt quá kích thước này thì các phần tử trước đó sẽ bị xoá. Nếu khoá chứa giá trị vô hướng, thì khoá đó sẽ tự động được chuyển đổi thành một chuỗi thời gian.
• remove: xoá nội dung liên kết với khoá đã cho.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Tất cả các khoá và giá trị được biểu thị trong Base64.

Các lệnh được liệt kê ở trên dùng để cung cấp ngữ nghĩa chèn, ghi đè và xoá ngữ nghĩa cho các tín hiệu vô hướng, cũng như chèn, bổ sung và ghi đè toàn bộ chuỗi đối với các tín hiệu chuỗi thời gian. Bạn phải quản lý ngữ nghĩa xoá và ghi đè trên các phần tử cụ thể của tín hiệu chuỗi thời gian trong quá trình mã hoá và nén; ví dụ: trong quá trình mã hoá, bỏ qua các giá trị trong một chuỗi thời gian đã được thay thế hoặc sửa và xoá chúng trong quá trình nén.

Các tín hiệu đã lưu trữ sẽ tự động được liên kết với ứng dụng đang thực hiện yêu cầu tìm nạp và phản hồi của yêu cầu ("site" hoặc "origin" của công nghệ quảng cáo đã đăng ký), cùng với thời gian tạo yêu cầu. Mọi tín hiệu phải được lưu trữ thay cho một công nghệ quảng cáo đã đăng ký Hộp cát về quyền riêng tư, "site"/"origin" của URI cần khớp với dữ liệu của một công nghệ quảng cáo đã đăng ký. Nếu công nghệ quảng cáo yêu cầu chưa được đăng ký, thì yêu cầu sẽ bị từ chối.

Hạn mức bộ nhớ và giải phóng bộ nhớ

Mỗi công nghệ quảng cáo có một lượng không gian giới hạn trên thiết bị của người dùng để lưu trữ các tín hiệu. Hạn mức này được xác định theo từng công nghệ quảng cáo, do đó, các tín hiệu được chọn từ các ứng dụng khác nhau sẽ có chung một hạn mức. Nếu vượt quá hạn mức, hệ thống sẽ giải phóng dung lượng bằng cách xoá các giá trị tín hiệu trước đó theo thứ tự vào trước xoá trước. Để tránh việc giải phóng quá thường xuyên, hệ thống sẽ triển khai logic phân lô để cho phép thấu chi hạn mức một lượng giới hạn và giải phóng thêm dung lượng sau khi logic loại bỏ được kích hoạt.

Mã hoá trên thiết bị để truyền dữ liệu

Để chuẩn bị các tín hiệu cho việc lựa chọn quảng cáo, logic tuỳ chỉnh trên mỗi người mua đã bảo vệ quyền truy cập vào các sự kiện và tín hiệu được lưu trữ cho mỗi ứng dụng. Công việc trong nền của hệ thống Android sẽ chạy hằng giờ để thực thi logic mã hoá tuỳ chỉnh cho mỗi người mua đã được tải xuống thiết bị. Logic mã hoá tuỳ chỉnh cho mỗi người mua sẽ mã hoá các tín hiệu cho mỗi ứng dụng, sau đó nén các tín hiệu cho mỗi ứng dụng vào một tải trọng tuân thủ hạn mức cho mỗi người mua. Sau đó, tải trọng được mã hoá trong phạm vi của bộ nhớ được bảo vệ của thiết bị, rồi được truyền đến các dịch vụ Đặt giá thầu và Phiên đấu giá.

Các công nghệ quảng cáo xác định mức độ xử lý tín hiệu được xử lý theo logic tuỳ chỉnh riêng. Ví dụ: bạn có thể đo lường giải pháp của mình để loại bỏ các tín hiệu trước đó và tổng hợp các tín hiệu tương tự hoặc tín hiệu củng cố từ nhiều ứng dụng thành các tín hiệu mới sử dụng ít dung lượng hơn.

Nếu người mua chưa đăng ký bộ mã hoá tín hiệu, thì các tín hiệu chưa được chuẩn bị và sẽ không có tín hiệu tuyển chọn trên thiết bị nào được gửi đến dịch vụ Đặt giá thầu và Phiên đấu giá.

Chúng tôi sẽ cung cấp thêm thông tin chi tiết về dung lượng lưu trữ, tải trọng và hạn mức yêu cầu trong thông tin cập nhật trong tương lai. Ngoài ra, chúng tôi sẽ cung cấp thêm thông tin về cách cung cấp các hàm tuỳ chỉnh.

Quy trình lựa chọn quảng cáo

Với đề xuất này, mã tuỳ chỉnh của công nghệ quảng cáo chỉ có thể truy cập vào Protected App Signals trong một Phiên đấu giá được bảo vệ (Ad Selection API) đang chạy trong TEE. Để hỗ trợ thêm nhu cầu cho trường hợp sử dụng lượt cài đặt ứng dụng, quảng cáo đề xuất sẽ được tìm nạp trong Phiên đấu giá được bảo vệ theo thời gian thực. Điều này trái ngược với trường hợp sử dụng tái tiếp thị mà trong đó quảng cáo đề xuất được biết đến trước phiên đấu giá.

Đề xuất này sử dụng quy trình lựa chọn quảng cáo tương tự như đề xuất Protected Audience với nội dung cập nhật để hỗ trợ trường hợp sử dụng cài đặt ứng dụng. Để hỗ trợ các yêu cầu tính toán cho kỹ thuật trích xuất tính chất và lựa chọn quảng cáo theo thời gian thực, các phiên đấu giá cho quảng cáo cài đặt ứng dụng phải chạy trên dịch vụ Đặt giá thầu và Phiên đấu giá chạy trong các TEE. Quyền truy cập vào Protected App Signals trong Phiên đấu giá được bảo vệ không được hỗ trợ trong các phiên đấu giá trên thiết bị.

Quy trình lựa chọn quảng cáo như sau:

1. SDK của người bán gửi tải trọng đã mã hoá trên thiết bị của Protected App Signals.
2. Máy chủ của người bán tạo một cấu hình cho phiên đấu giá và gửi cấu hình đó đến dịch vụ Đặt giá thầu và Phiên đấu giá đáng tin cậy của người bán cùng với tải trọng được mã hoá để bắt đầu quy trình lựa chọn quảng cáo.
3. Dịch vụ Đặt giá thầu và Phiên đấu giá của người bán sẽ truyền tải trọng đến các máy chủ giao diện người dùng đáng tin cậy của những người mua tham gia.
4. Dịch vụ đặt giá thầu của người mua sẽ thực thi logic lựa chọn quảng cáo của bên mua
   1. Thực thi logic truy xuất quảng cáo của bên mua.
   2. Thực thi logic đặt giá thầu của bên mua.
5. Thực thi logic tính điểm của bên bán.
6. Quảng cáo được hiển thị và bắt đầu báo cáo.

Bắt đầu quy trình lựa chọn quảng cáo

Khi một ứng dụng sẵn sàng hiển thị quảng cáo, SDK công nghệ quảng cáo (thường là SSP) sẽ bắt đầu quy trình lựa chọn quảng cáo bằng cách gửi mọi dữ liệu theo bối cảnh có liên quan từ nhà xuất bản và tải trọng được mã hoá cho mỗi người mua để được đưa vào yêu cầu gửi đến Phiên đấu giá được bảo vệ bằng lệnh gọi getAdSelectionData. Đây cũng là API được dùng cho quy trình tái tiếp thị và được mô tả trong đề xuất Tích hợp tính năng Đặt giá thầu và Phiên đấu giá cho Android.

Để bắt đầu lựa chọn quảng cáo, người bán truyền danh sách những người mua tham gia và tải trọng đã mã hoá của Protected App Signals trên thiết bị. Với thông tin này, máy chủ quảng cáo của bên bán chuẩn bị một SelectAdRequest cho dịch vụ SellerFrontEnd đáng tin cậy của mình.

Người bán đặt các thông tin sau:

• Tải trọng nhận được từ getAdSelectionData, chứa Protected App Signals.

• Các tín hiệu bối cảnh sử dụng:

  • auction_config.auction_signals (để biết thông tin về phiên đấu giá)

  • auction_config.seller_signals (đối với tín hiệu của người bán)

  • auction_config.per_buyer_config["buyer"].buyer_signals (đối với tín hiệu của người mua)

• Danh sách người mua có trong phiên đấu giá bằng cách dùng trường buyer_list.

Thực thi logic lựa chọn quảng cáo phía bên mua

Ở cấp độ cao, logic tuỳ chỉnh của người mua sử dụng dữ liệu theo bối cảnh do nhà xuất bản và Protected App Signals cung cấp để chọn và áp dụng giá thầu cho các quảng cáo phù hợp trong yêu cầu quảng cáo. Nền tảng này cho phép người mua thu hẹp một lượng lớn quảng cáo có sẵn cho những quảng cáo phù hợp nhất (k quảng cáo hàng đầu), trong đó giá thầu được tính toán trước khi quảng cáo được trả về cho người bán để đưa ra lựa chọn cuối cùng.

Trước khi đặt giá thầu, người mua sẽ bắt đầu với một nhóm lớn các quảng cáo. Việc tính toán giá thầu cho mỗi quảng cáo quá chậm. Vì vậy, trước tiên, người mua cần chọn k đề xuất hàng đầu trong nhóm lớn. Tiếp theo, những người mua cần tính toán giá thầu cho từng k ứng viên hàng đầu đó. Sau đó, các quảng cáo và giá thầu đó được trả về cho người bán để đưa ra lựa chọn cuối cùng.

1. Dịch vụ BuyerFrontEnd nhận được yêu cầu quảng cáo.
2. Dịch vụ BuyerFrontEnd sẽ gửi yêu cầu đến dịch vụ đặt giá thầu của người mua. Dịch vụ đặt giá thầu của người mua chạy một UDF có tên là prepareDataForAdRetrieval(). UDF này sẽ tạo một yêu cầu để nhận k đề xuất hàng đầu từ Dịch vụ truy xuất quảng cáo. Dịch vụ đặt giá thầu sẽ gửi yêu cầu này đến điểm cuối của máy chủ truy xuất đã định cấu hình.
3. Dịch vụ truy xuất quảng cáo chạy UDF getCandidateAds(), sẽ lọc ra tập hợp k quảng cáo đề xuất hàng đầu được gửi đến dịch vụ đặt giá thầu của người mua.
4. Dịch vụ đặt giá thầu của người mua chạy UDF generateBid(), sẽ chọn đề xuất phù hợp nhất, tính toán giá thầu, sau đó trả về dịch vụ BuyerFrontEnd.
5. Dịch vụ BuyerFrontEnd trả về các quảng cáo và giá thầu cho người bán.

Có một số thông tin quan trọng về quy trình này – đặc biệt là về cách các phần kết nối với nhau và cách nền tảng cung cấp các tính năng như khả năng đưa ra dự đoán của công nghệ học máy để truy xuất k quảng cáo hàng đầu và để tính toán giá thầu.

Trước khi chúng ta tìm hiểu chi tiết hơn về các phần của vấn đề này, có một số lưu ý quan trọng về cấu trúc của các TEE trong biểu đồ ở trên.

Dịch vụ đặt giá thầu của người mua có chứa dịch vụ suy luận trong nội bộ. Công nghệ quảng cáo có thể tải các mô hình học máy lên dịch vụ đặt giá thầu của người mua. Chúng tôi sẽ cung cấp các API JavaScript cho các công nghệ quảng cáo để đưa ra dự đoán hoặc tạo các mục nhúng từ các mô hình này từ trong các UDF đang chạy trên dịch vụ đặt giá thầu của người mua. Không giống như Dịch vụ truy xuất quảng cáo, dịch vụ đặt giá thầu của người mua không có dịch vụ khoá-giá trị để lưu trữ bất kỳ siêu dữ liệu quảng cáo nào.

Dịch vụ truy xuất quảng cáo bao gồm dịch vụ khoá-giá trị trong nội bộ. Các công nghệ quảng cáo có thể hiện thực hoá các cặp khoá-giá trị vào dịch vụ này từ các máy chủ của riêng chúng, bên ngoài ranh giới quyền riêng tư. Chúng tôi sẽ cung cấp API JavaScript cho các công nghệ quảng cáo để đọc từ dịch vụ khoá-giá trị này từ trong UDF đang chạy trên Dịch vụ truy xuất quảng cáo. Không giống như dịch vụ đặt giá thầu của người mua, Dịch vụ truy xuất quảng cáo không chứa dịch vụ suy luận.

Một câu hỏi trọng tâm mà kiểu thiết kế này giải quyết được là làm thế nào để đưa ra các dự đoán tại thời điểm truy xuất cũng như tại thời điểm đặt giá thầu. Câu trả lời cho cả hai có thể liên quan đến một giải pháp tên là phân tích mô hình.

Phân tích mô hình

Phân tích mô hình là một kỹ thuật giúp bạn có thể chia một mô hình duy nhất thành nhiều phần, sau đó kết hợp các phần đó vào một thông tin dự đoán. Trong trường hợp sử dụng Cài đặt ứng dụng, các mô hình thường sử dụng 3 loại dữ liệu: dữ liệu người dùng, dữ liệu bối cảnh và dữ liệu quảng cáo.

Trong trường hợp không được phân tích, một mô hình duy nhất sẽ được huấn luyện dựa trên cả 3 loại dữ liệu. Trong trường hợp được phân tích, chúng ta sẽ chia mô hình thành nhiều phần. Chỉ phần chứa dữ liệu người dùng là nhạy cảm. Điều đó có nghĩa là chỉ mô hình có phần người dùng cần chạy bên trong ranh giới tin cậy, trên dịch vụ suy luận của dịch vụ đặt giá thầu của người mua.

Điều đó giúp thiết kế sau đây có thể:

1. Chia mô hình này thành một phần riêng tư (dữ liệu người dùng) và một hoặc nhiều phần không riêng tư (dữ liệu quảng cáo và ngữ cảnh).
2. Bạn có thể truyền một số hoặc tất cả các phần không riêng tư dưới dạng các đối số cho UDF mà cần đưa ra dự đoán. Ví dụ: mục nhúng theo ngữ cảnh được chuyển đến các UDF trong per_buyer_signals.
3. Nếu muốn, các công nghệ quảng cáo có thể tạo mô hình cho các phần không riêng tư, sau đó hiện thực hoá các mục nhúng từ các mô hình đó vào kho khoá-giá trị của Dịch vụ truy xuất quảng cáo. Các UDF trên Dịch vụ truy xuất quảng cáo có thể tìm nạp các mục nhúng này trong thời gian chạy.
4. Để đưa ra dự đoán trong UDF, hãy kết hợp các mục nhúng riêng tư từ dịch vụ suy luận với các mục nhúng không riêng tư từ các đối số hàm UDF hoặc kho khoá-giá trị bằng một thao tác như phép tính tích vô hướng. Đây là dự đoán cuối cùng.

Như đã giải thích, chúng ta có thể xem xét chi tiết hơn về từng UDF. Chúng tôi sẽ giải thích chức năng của các UDF này, cách chúng tích hợp và cách chúng có thể đưa ra các dự đoán cần thiết để chọn k quảng cáo hàng đầu và tính toán giá thầu của chúng.

UDF prepareDataForAdRetrieval()

prepareDataForAdRetrieval() chạy trên dịch vụ đặt giá thầu của người mua sẽ chịu trách nhiệm tạo tải trọng yêu cầu sẽ được gửi đến dịch vụ truy xuất quảng cáo để tìm nạp k quảng cáo đề xuất hàng đầu.

prepareDataForAdRetrieval() sẽ lấy những thông tin sau:

• Tải trọng trên mỗi người mua nhận được từ getAdSelectionData. Tải trọng này chứa Protected App Signals.
• auction_signals của tín hiệu bối cảnh (cho thông tin về phiên đấu giá) và buyer_signals (cho các trường tín hiệu của người mua).

prepareDataForAdRetrieval() thực hiện 2 việc:

• Điều chỉnh: nếu cần suy luận tại thời điểm truy xuất, tính năng này sẽ biến các tín hiệu đến thành các tính năng để sử dụng trong các lệnh gọi đến dịch vụ suy luận nhằm nhận được các chế độ nhúng riêng tư cho việc truy xuất.
• Tính toán các mục nhúng riêng tư để truy xuất: nếu cần dự đoán truy xuất, tính năng này sẽ thực hiện lệnh gọi dựa trên dịch vụ suy luận bằng cách sử dụng các tính năng trên và nhận một chế độ nhúng riêng tư cho các dự đoán tại thời điểm truy xuất.

prepareDataForAdRetrieval() trả về:

• Protected App Signals: tải trọng tín hiệu do công nghệ quảng cáo tuyển chọn.
• Tín hiệu dành riêng cho phiên đấu giá: tín hiệu bên bán dành riêng cho nền tảng và thông tin ngữ cảnh như auction_signals và per_buyer_signals (bao gồm tính năng nhúng theo ngữ cảnh) từ SelectAdRequest. Điều này tương tự như Protected Audience.
• Tín hiệu bổ sung: thông tin bổ sung như tính năng nhúng riêng tư được truy xuất từ dịch vụ suy luận.

Yêu cầu này được gửi đến Dịch vụ truy xuất quảng cáo. Dịch vụ này sẽ so khớp đề xuất rồi chạy UDF getCandidateAds().

UDF getCandidateAds()

getCandidateAds() sẽ chạy trên Dịch vụ truy xuất quảng cáo. Dịch vụ đó nhận được yêu cầu do prepareDataForAdRetrieval() tạo trên dịch vụ đặt giá thầu của người mua. Dịch vụ này thực thi getCandidateAds() để tìm nạp các đề xuất hàng đầu để đặt giá thầu bằng cách chuyển đổi yêu cầu thành một loạt các truy vấn đã đặt, tìm nạp dữ liệu và thực thi logic nghiệp vụ tuỳ chỉnh cũng như logic truy xuất tuỳ chỉnh khác.

getCandidateAds() sẽ lấy những thông tin sau:

• Protected App Signals: tải trọng tín hiệu do công nghệ quảng cáo tuyển chọn.
• Tín hiệu dành riêng cho phiên đấu giá: tín hiệu bên bán dành riêng cho nền tảng và thông tin ngữ cảnh như auction_signals và per_buyer_signals (bao gồm tính năng nhúng theo ngữ cảnh) từ SelectAdRequest. Điều này tương tự như Protected Audience.
• Tín hiệu bổ sung: thông tin bổ sung như tính năng nhúng riêng tư được truy xuất từ dịch vụ suy luận.

getCandidateAds() sẽ thực hiện những việc sau:

1. Tìm nạp tập hợp các đề xuất quảng cáo ban đầu: Được tìm nạp bằng cách sử dụng các tiêu chí nhắm mục tiêu như ngôn ngữ, địa lý, loại quảng cáo, kích thước quảng cáo hoặc ngân sách, để lọc các đề xuất quảng cáo.
2. Tìm nạp nhúng truy xuất: Nếu cần nhúng từ dịch vụ khoá-giá trị để dự đoán thời gian truy xuất cho k lựa chọn hàng đầu, thì những hoạt động này phải được truy xuất từ dịch vụ khoá-giá trị.
3. k lựa chọn đề xuất hàng đầu: Tính điểm số nhỏ cho tập hợp các đề xuất quảng cáo đã lọc dựa trên siêu dữ liệu quảng cáo được tìm nạp từ kho khoá-giá trị và thông tin gửi từ dịch vụ đặt giá thầu của người mua và để chọn ra những đề xuất hàng đầu dựa trên điểm số đó. Ví dụ: điểm số này có thể là cơ hội cài đặt một ứng dụng đã cung cấp quảng cáo.
4. Tìm nạp mục nhúng đặt giá thầu: nếu cần các mục nhúng từ dịch vụ khoá-giá trị bằng mã đặt giá thầu để đưa ra thông tin dự đoán tại thời điểm đặt giá thầu, thì có thể được truy xuất từ dịch vụ khoá-giá trị.

Xin lưu ý rằng điểm số của một quảng cáo có thể là kết quả của mô hình dự đoán. Ví dụ: Điểm này sẽ dự đoán xác suất người dùng cài đặt ứng dụng. Loại hình tạo điểm số này liên quan đến một loại phân tích mô hình: vì getCandidateAds() chạy trên Dịch vụ truy xuất quảng cáo và dịch vụ truy xuất quảng cáo không có dịch vụ suy luận, các dự đoán có thể được tạo bằng cách kết hợp:

• Các mục nhúng theo ngữ cảnh được truyền vào bằng cách sử dụng đầu vào tín hiệu dành riêng cho phiên đấu giá.
• Các mục nhúng riêng tư được truyền bằng cách sử dụng đầu vào tín hiệu bổ sung.
• Mọi công nghệ quảng cáo mục nhúng không riêng tư đều đã được cụ thể hoá từ các máy chủ của chúng vào dịch vụ khoá-giá trị của Dịch vụ truy xuất quảng cáo.

Xin lưu ý rằng UDF generateBid() chạy trên dịch vụ đặt giá thầu của người mua cũng có thể áp dụng loại phân tích mô hình riêng để đưa ra dự đoán về việc đặt giá thầu. Nếu cần có dịch vụ khoá-giá trị để thực hiện việc này, bạn phải tìm nạp ngay các mục nhúng đó.

getCandidateAds() trả về:

• Quảng cáo đề xuất: k quảng cáo hàng đầu sẽ được chuyển đến generateBid(). Mỗi quảng cáo bao gồm:
  • URL hiển thị: điểm cuối để hiển thị mẫu quảng cáo.
  • Siêu dữ liệu: siêu dữ liệu quảng cáo dành riêng cho công nghệ quảng cáo, phía bên mua Ví dụ: siêu dữ liệu này có thể bao gồm thông tin về chiến dịch quảng cáo và tiêu chí nhắm mục tiêu, chẳng hạn như vị trí và ngôn ngữ. Siêu dữ liệu có thể bao gồm các mục nhúng không bắt buộc được dùng khi cần có hoạt động phân tích mô hình để chạy lượt suy luận trong quá trình đặt giá thầu.
• Tín hiệu bổ sung: Nếu muốn, Dịch vụ truy xuất quảng cáo có thể bao gồm thông tin bổ sung, chẳng hạn như các mục nhúng hoặc tín hiệu rác bổ sung sẽ được dùng trong generateBid().

Chúng tôi đang điều tra các phương pháp khác để cung cấp các quảng cáo được tính điểm, bao gồm cả việc đưa quảng cáo đó vào lệnh gọi SelectAdRequest. Bạn có thể truy xuất các quảng cáo này bằng cách sử dụng yêu cầu giá thầu RTB. Xin lưu ý rằng trong các trường hợp như vậy, bạn phải truy xuất các quảng cáo mà không cần đến Protected App Signals. Chúng tôi dự đoán rằng các công nghệ quảng cáo sẽ đánh giá các yếu tố đánh đổi trước khi chọn phương án tốt nhất, bao gồm cả kích thước tải trọng phản hồi, độ trễ, chi phí cũng như tính sẵn có của tín hiệu.

UDF generateBid()

Sau khi truy xuất tập hợp các quảng cáo đề xuất và các mục nhúng trong quá trình truy xuất, bạn có thể chuyển sang bước đặt giá thầu. Thao tác này sẽ chạy trong dịch vụ đặt giá thầu của người mua. Dịch vụ này chạy UDF generateBid() do người mua cung cấp để chọn quảng cáo để đặt giá thầu từ k hàng đầu, sau đó trả về quảng cáo cùng với giá thầu.

generateBid() lấy những thông tin sau:

• Quảng cáo đề xuất: k quảng cáo hàng đầu do dịch vụ Truy xuất quảng cáo truy xuất trả về.
• Tín hiệu dành riêng cho phiên đấu giá: tín hiệu bên bán dành riêng cho nền tảng và thông tin ngữ cảnh như auction_signals và per_buyer_signals (bao gồm tính năng nhúng theo ngữ cảnh) từ SelectAdRequest.
• Tín hiệu bổ sung: thông tin bổ sung được sử dụng tại thời điểm đặt giá thầu.

Việc triển khai generateBid() của người mua thực hiện 3 việc:

• Liên kết: biến đổi các tín hiệu thành các tính năng để sử dụng trong quá trình suy luận.
• Suy luận: tạo các thông tin dự đoán bằng các mô hình học máy để tính toán các giá trị như số lượt nhấp được dự đoán và tỷ lệ chuyển đổi.
• Đặt giá thầu: kết hợp các giá trị suy luận với các thông tin đầu vào khác để tính toán giá thầu cho quảng cáo đề xuất.

generateBid() trả về:

• Quảng cáo đề xuất.
• Đây là số tiền giá thầu được tính toán.

Xin lưu ý rằng generateBid() được dùng cho Quảng cáo cài đặt ứng dụng và quảng cáo được dùng cho Quảng cáo tái tiếp thị khác nhau.

Các phần sau đây sẽ mô tả chi tiết hơn về việc liên kết, suy luận và đặt giá thầu.

Liên kết

generateBid() có thể chuẩn bị tín hiệu phiên đấu giá trong các tính năng. Có thể sử dụng các tính năng này trong quá trình suy luận để dự đoán những chỉ số như số lượt nhấp và tỷ lệ chuyển đổi. Chúng tôi cũng đang tìm hiểu các cơ chế bảo đảm quyền riêng tư để truyền một số cơ chế đó trong báo cáo giành chiến thắng để sử dụng trong quá trình huấn luyện mô hình.

Suy luận

Trong khi tính toán giá thầu, thông thường, bạn nên tiến hành suy luận dựa trên một hoặc nhiều mô hình học máy. Ví dụ: các phép tính eCPM hiệu quả thường dùng các mô hình để dự đoán tỷ lệ nhấp và tỷ lệ chuyển đổi.

Các ứng dụng có thể cung cấp một số mô hình học máy cùng với việc triển khai generateBid(). Chúng tôi cũng sẽ cung cấp API JavaScript trong generateBid() để ứng dụng có thể tiến hành suy luận trong thời gian chạy.

Quá trình suy luận thực thi trên dịch vụ đặt giá thầu của người mua. Điều này có thể ảnh hưởng đến độ trễ và chi phí suy luận, đặc biệt là vì trình tăng tốc chưa có sẵn trong các TEE. Một số khách hàng sẽ thấy nhu cầu của họ được đáp ứng thông qua các mô hình riêng lẻ chạy trên dịch vụ đặt giá thầu của người mua. Một số ứng dụng (ví dụ: những ứng dụng có mô hình rất lớn) có thể muốn xem xét các lựa chọn như phân tích mô hình để giảm thiểu chi phí suy luận và độ trễ tại thời điểm đặt giá thầu.

Thông tin thêm về khả năng suy luận, chẳng hạn như các định dạng mô hình được hỗ trợ và kích thước tối đa, sẽ được cung cấp trong bản cập nhật trong tương lai.

Triển khai quá trình phân tích mô hình

Trước đó, chúng tôi đã giải thích về phân tích mô hình. Tại thời điểm đặt giá thầu, phương pháp cụ thể là:

1. Chia mô hình đơn lẻ thành một phần riêng tư (dữ liệu người dùng) và một hoặc nhiều phần không riêng tư (dữ liệu quảng cáo và theo ngữ cảnh).
2. Truyền các phần không riêng tư vào generateBid(). Các phần này có thể đến từ per_buyer_signals hoặc từ các mục nhúng mà công nghệ quảng cáo tính toán bên ngoài, hiện thực hoá vào kho khoá-giá trị của dịch vụ truy xuất, tìm nạp tại thời điểm truy xuất và trả về như một phần của các tín hiệu bổ sung. Phần này không bao gồm các mục nhúng riêng tư vì chúng không thể bắt nguồn từ bên ngoài ranh giới quyền riêng tư.
3. Trong generateBid():
   1. Tiến hành suy luận dựa trên các mô hình để nhận các mục nhúng riêng tư dành cho người dùng.
   2. Kết hợp các mục nhúng riêng tư của người dùng với các mục nhúng theo ngữ cảnh từ per_buyer_signals hoặc quảng cáo không phải quảng cáo riêng tư và các mục nhúng theo ngữ cảnh từ dịch vụ truy xuất bằng cách sử dụng một thao tác như phép tính tích vô hướng. Đây là dự đoán cuối cùng có thể được dùng để tính toán giá thầu.

Bằng cách sử dụng phương pháp này, bạn có thể tiến hành suy luận tại thời điểm đặt giá thầu dựa trên các mô hình quá lớn hoặc quá chậm để thực thi trên dịch vụ đặt giá thầu của người mua.

Logic tính điểm của bên bán

Ở giai đoạn này, quảng cáo có giá thầu nhận được từ tất cả những người mua tham gia sẽ được tính điểm. Đầu ra của generateBid() được chuyển đến dịch vụ đấu giá của người bán để chạy scoreAd() và scoreAd() chỉ xem xét một quảng cáo tại một thời điểm. Dựa trên tính điểm, người bán chọn một quảng cáo giành chiến thắng để quay lại thiết bị để hiển thị.

Logic tính điểm được dùng giống nhau cho quy trình tái tiếp thị của Protected Audience và có thể chọn quảng cáo giành chiến thắng trong số các đề xuất tái tiếp thị và cài đặt ứng dụng. Hàm này được gọi một lần cho mỗi quảng cáo đề xuất đã gửi trong Phiên đấu giá được bảo vệ. Hãy xem nội dung giải thích về Đặt giá thầu và Phiên đấu giá để biết thông tin chi tiết.

Thời gian chạy của đoạn mã lựa chọn quảng cáo

Trong đề xuất, mã lựa chọn quảng cáo cho lượt cài đặt ứng dụng được chỉ định theo cách giống với mã cho quy trình tái tiếp thị của Protected Audience. Để biết thông tin chi tiết, hãy xem phần Cấu hình Đặt giá thầu và Phiên đấu giá. Mã đặt giá thầu sẽ có sẵn ở cùng một vị trí bộ nhớ trên đám mây của mã đặt giá thầu dùng để tái tiếp thị.

Báo cáo

Đề xuất này sử dụng cùng các API báo cáo như đề xuất báo cáo Protected Audience (ví dụ: reportImpression(), kích hoạt nền tảng gửi báo cáo cho người bán và người mua).

Một trường hợp sử dụng phổ biến của báo cáo về bên mua là lấy dữ liệu huấn luyện cho các mô hình được sử dụng trong quá trình lựa chọn quảng cáo. Ngoài các API hiện có, nền tảng này sẽ cung cấp một cơ chế cụ thể để chuyển dữ liệu cấp sự kiện từ nền tảng đến máy chủ công nghệ quảng cáo. Các tải trọng đầu ra này có thể bao gồm một số dữ liệu người dùng nhất định.

Về lâu dài, chúng tôi đang điều tra các giải pháp bảo đảm quyền riêng tư để giải quyết việc huấn luyện mô hình bằng dữ liệu được sử dụng trong Phiên đấu giá được bảo vệ mà không cần gửi dữ liệu người dùng cấp sự kiện ra ngoài các dịch vụ chạy trên TEE. Chúng tôi sẽ cung cấp thêm thông tin chi tiết trong nội dung cập nhật sau này.

Trong ngắn hạn, chúng tôi sẽ cung cấp một cách tạm thời để thoát dữ liệu bị nhiễu từ generateBid(). Đề xuất ban đầu của chúng tôi về việc này được trình bày bên dưới và chúng tôi sẽ phát triển đề xuất này (bao gồm cả những thay đổi có thể không tương thích ngược) để phản hồi ý kiến phản hồi của ngành.

Về mặt kỹ thuật, cách thức hoạt động của tính năng này như sau:

1. Công nghệ quảng cáo xác định giản đồ cho dữ liệu mà họ muốn truyền.
2. Trong generateBid(), các ứng dụng này sẽ tạo tải trọng đầu ra mong muốn.
3. Nền tảng xác thực tải trọng đầu ra dựa trên giản đồ và thực thi giới hạn kích thước.
4. Nền tảng này thêm nhiễu vào tải trọng đầu ra.
5. Trọng tải thoát được đưa vào báo cáo chiến thắng ở định dạng dây, được nhận trên máy chủ công nghệ quảng cáo, giải mã và dùng để huấn luyện mô hình.

Xác định giản đồ của tải trọng đầu ra

Để nền tảng thực thi các yêu cầu về quyền riêng tư đang phát triển, tải trọng đầu ra phải được cấu trúc theo cách mà nền tảng có thể hiểu được. Công nghệ quảng cáo sẽ xác định cấu trúc của tải trọng thoát bằng cách cung cấp tệp JSON giản đồ. Nền tảng sẽ xử lý giản đồ đó và các dịch vụ Đặt giá thầu và Phiên đấu giá sẽ giữ bí mật bằng cùng một cơ chế như các tài nguyên công nghệ quảng cáo khác như UDF và mô hình.

Chúng tôi sẽ cung cấp một tệp CDDL xác định cấu trúc của JSON đó. Tệp CDDL sẽ bao gồm một tập hợp các loại tính năng được hỗ trợ (ví dụ: các tính năng là boolean, số nguyên, bộ chứa, v.v.). Cả tệp CDDL và giản đồ được cung cấp sẽ được tạo phiên bản.

Ví dụ: một tải trọng thoát bao gồm một tính năng boolean duy nhất, theo sau là một tính năng bộ chứa có kích thước 2 sẽ có dạng như sau:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Bạn có thể xem thông tin chi tiết về tập hợp các loại tính năng được hỗ trợ trên GitHub.

Tạo tải trọng đầu ra trong generateBid()

Tất cả Protected App Signals cho một người mua nhất định đều có sẵn cho UDF generateBid() của họ. Sau khi được đưa vào tính năng, các công nghệ quảng cáo sẽ tạo tải trọng ở định dạng JSON. Gói dữ liệu đầu ra này sẽ được đưa vào báo cáo chiến thắng của người mua để truyền đến các máy chủ công nghệ quảng cáo.

Một giải pháp thay thế cho thiết kế này là tính toán vectơ thoát trong reportWin() thay vì generateBid(). Mỗi phương pháp đều có ưu và khuyết điểm. Chúng tôi sẽ đưa ra quyết định cuối cùng dựa trên ý kiến phản hồi của ngành.

Xác thực tải trọng đầu ra

Nền tảng sẽ xác thực mọi tải trọng thoát do công nghệ quảng cáo tạo ra. Quy trình xác thực đảm bảo rằng các giá trị tính năng hợp lệ cho loại của chúng, đáp ứng các quy tắc hạn chế về kích thước và các bên độc hại không cố gắng đánh bại các biện pháp kiểm soát quyền riêng tư bằng cách đóng gói thông tin bổ sung vào tải trọng thoát của chúng.

Nếu tải trọng đầu ra không hợp lệ, thì tải trọng đó sẽ bị loại bỏ khỏi dữ liệu đầu vào được gửi đến báo cáo chiến thắng. Lý do là chúng tôi không muốn cung cấp thông tin gỡ lỗi cho bất kỳ đối tượng xấu nào cố gắng đánh bại quy trình xác thực.

Chúng tôi sẽ cung cấp API JavaScript cho các công nghệ quảng cáo để đảm bảo tải trọng đầu ra mà họ tạo trong generateBid() sẽ vượt qua quy trình xác thực nền tảng:

validate(payload, schema)

API JavaScript này hoàn toàn dành cho phương thức gọi để xác định xem một tải trọng cụ thể có vượt qua quy trình xác thực nền tảng hay không. Bạn phải thực hiện quy trình xác thực thực tế trong nền tảng để bảo vệ khỏi các UDF generateBid() độc hại.

Làm nhiễu tải trọng đầu ra

Nền tảng sẽ loại bỏ các tải trọng đầu ra trước khi đưa chúng vào báo cáo chiến thắng. Ngưỡng nhiễu ban đầu sẽ là 1% và giá trị này có thể thay đổi theo thời gian. Nền tảng sẽ không cho biết lượng hàng trọng đi ra cụ thể có bị nhiễu hay không.

Phương thức tạo nhiễu là:

1. Nền tảng sẽ tải định nghĩa giản đồ cho tải trọng đầu ra.
2. 1% tải trọng đầu ra sẽ được chọn để tạo nhiễu.
3. Nếu bạn không chọn tải trọng đầu ra, toàn bộ giá trị ban đầu sẽ được giữ lại.
4. Nếu bạn chọn tải trọng đầu ra, thì giá trị của mỗi đặc điểm sẽ được thay thế bằng một giá trị hợp lệ ngẫu nhiên cho loại đặc điểm đó (ví dụ: 0 hoặc 1 cho một đặc điểm boolean).

Truyền, nhận và giải mã tải trọng đầu ra để huấn luyện mô hình

Tải trọng đầu ra đã xác thực và bị nhiễu sẽ được đưa vào các đối số của reportWin() và được truyền đến các máy chủ công nghệ quảng cáo của người mua bên ngoài ranh giới quyền riêng tư để huấn luyện mô hình. Tải trọng đầu ra sẽ ở định dạng dây.

Bạn có thể xem thông tin chi tiết về định dạng dây cho tất cả các loại tính năng và cho chính tải trọng đầu ra trên GitHub.

Xác định kích thước tải trọng đầu ra

Kích thước tải trọng đầu ra tính bằng bit giúp cân bằng giữa tiện ích và việc giảm thiểu dữ liệu. Chúng tôi sẽ làm việc với các bên trong ngành để xác định kích thước phù hợp thông qua thử nghiệm. Trong khi chạy các thử nghiệm đó, chúng tôi sẽ tạm thời xuất dữ liệu mà không giới hạn kích thước bit. Dữ liệu thoát bổ sung đó không có giới hạn kích thước bit sẽ bị xoá sau khi thử nghiệm hoàn tất.

Phương thức xác định kích thước là:

1. Ban đầu, chúng tôi sẽ hỗ trợ hai tải trọng đầu ra trong generateBid():
   1. egressPayload: tải trọng đầu ra có giới hạn kích thước mà chúng tôi đã mô tả cho đến nay trong tài liệu này. Ban đầu, kích thước của tải trọng đầu ra này sẽ là 0 bit (tức là tải trọng này sẽ luôn bị xoá trong quá trình xác thực).
   2. temporaryUnlimitedEgressPayload: tải trọng đầu ra tạm thời không giới hạn kích thước cho các thử nghiệm về kích thước. Việc định dạng, tạo và xử lý tải trọng đầu ra này sử dụng các cơ chế tương tự như egressPayload.
2. Mỗi gói dữ liệu đầu ra này sẽ có một tệp JSON giản đồ riêng: egress_payload_schema.json và temporary_egress_payload_schema.json.
3. Chúng tôi cung cấp một giao thức thử nghiệm và một bộ chỉ số để xác định tiện ích của mô hình ở nhiều kích thước tải trọng đầu ra (ví dụ: 5, 10, ... bit).
4. Dựa trên kết quả thử nghiệm, chúng tôi xác định kích thước tải trọng đầu ra với mức độ đánh đổi chính xác giữa tiện ích và quyền riêng tư.
5. Chúng ta đặt kích thước của egressPayload từ 0 bit thành kích thước mới.
6. Sau một khoảng thời gian di chuyển đã đặt, chúng ta sẽ xoá temporaryUnlimitedEgressPayload, chỉ để lại egressPayload với kích thước mới.

Chúng tôi đang điều tra các biện pháp bảo vệ kỹ thuật bổ sung để quản lý thay đổi này (ví dụ: mã hoá egressPayload khi chúng tôi tăng kích thước của egressPayload từ 0 bit). Thông tin chi tiết đó – cùng với thời gian thử nghiệm và việc xoá temporaryUnlimitedEgressPayload – sẽ được đưa vào bản cập nhật sau này.

Tiếp theo, chúng ta sẽ giải thích một giao thức thử nghiệm có thể dùng để hoàn tất kích thước của egressPayload. Mục tiêu của chúng tôi là làm việc với ngành để tìm ra kích thước cân bằng giữa tính hữu dụng và việc giảm thiểu dữ liệu. Cấu phần phần mềm mà các thử nghiệm này sẽ tạo ra là một biểu đồ, trong đó trục x là kích thước của tải trọng huấn luyện tính bằng bit và trục y là tỷ lệ phần trăm doanh thu do một mô hình tạo ra ở kích thước đó so với đường cơ sở không giới hạn kích thước.

Chúng ta sẽ giả định rằng chúng ta đang huấn luyện một mô hình pInstall và nguồn dữ liệu huấn luyện của chúng ta là nhật ký và nội dung của temporaryUnlimitedegressPayload mà chúng ta nhận được khi giành chiến thắng trong phiên đấu giá. Trước tiên, giao thức cho công nghệ quảng cáo liên quan đến các thử nghiệm ngoại tuyến:

1. Xác định cấu trúc của các mô hình mà họ sẽ sử dụng với Protected App Signals. Ví dụ: họ sẽ cần xác định xem có sử dụng phân tích mô hình hay không.
2. Xác định một chỉ số để đo lường chất lượng mô hình. Các chỉ số được đề xuất là tổn thất AUC và tổn thất theo hàm log.
3. Xác định tập hợp các tính năng mà chúng sẽ sử dụng trong quá trình huấn luyện mô hình.
4. Bằng cách sử dụng cấu trúc mô hình, chỉ số chất lượng và tập hợp các tính năng huấn luyện đó, hãy chạy các nghiên cứu loại bỏ để xác định tiện ích đóng góp trên mỗi bit cho từng mô hình mà họ muốn sử dụng trong PAS. Giao thức đề xuất cho nghiên cứu ablation là:
   1. Huấn luyện mô hình bằng tất cả các tính năng và đo lường mức độ hữu ích; đây là đường cơ sở để so sánh.
   2. Đối với mỗi đặc điểm dùng để tạo đường cơ sở, hãy huấn luyện mô hình bằng tất cả các đặc điểm ngoại trừ đặc điểm đó.
   3. Đo lường tiện ích thu được. Chia delta cho kích thước của tính năng tính bằng bit; đây là mức tiện ích dự kiến trên mỗi bit cho tính năng đó.
5. Xác định kích thước tải trọng huấn luyện mà bạn quan tâm để thử nghiệm. Bạn nên sử dụng [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit. Mỗi giá trị này đại diện cho một kích thước có thể có của egressPayload mà thử nghiệm sẽ đánh giá.
6. Đối với mỗi kích thước có thể có, hãy chọn một tập hợp các tính năng nhỏ hơn hoặc bằng kích thước đó để tối đa hoá tiện ích trên mỗi bit, sử dụng kết quả của nghiên cứu loại bỏ.
7. Huấn luyện một mô hình cho mỗi kích thước có thể có và đánh giá mức độ hữu ích của mô hình đó dưới dạng tỷ lệ phần trăm mức độ hữu ích của mô hình cơ sở được huấn luyện trên tất cả các tính năng.
8. Lập biểu đồ kết quả, trong đó trục x là kích thước của tải trọng đào tạo tính bằng bit và trục y là tỷ lệ phần trăm doanh thu do mô hình đó tạo ra so với đường cơ sở.

Tiếp theo, công nghệ quảng cáo có thể lặp lại các bước 5-8 trong thử nghiệm lưu lượng truy cập trực tiếp, sử dụng dữ liệu tính năng được gửi qua temporaryUnlimitedEgressPayload. Công nghệ quảng cáo có thể chọn chia sẻ kết quả của các thử nghiệm lưu lượng truy cập ngoại tuyến và trực tiếp với Hộp cát về quyền riêng tư để đưa ra quyết định về kích thước của egressPayload.

Tiến trình của các thử nghiệm này, cũng như tiến trình đặt kích thước của egressPayload thành giá trị thu được, nằm ngoài phạm vi của tài liệu này và sẽ được đề cập trong bản cập nhật sau.

Biện pháp bảo vệ dữ liệu

Chúng tôi sẽ áp dụng một số biện pháp bảo vệ cho dữ liệu đã chuyển ra bên ngoài, bao gồm:

1. Cả egressPayload và temporaryUnlimitedEgressPayload đều bị nhiễu.
2. Để giảm thiểu và bảo vệ dữ liệu, temporaryUnlimitedEgressPayload sẽ chỉ có sẵn trong thời gian thử nghiệm kích thước, trong đó chúng tôi sẽ xác định kích thước chính xác cho egressPayload.

Quyền

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

• Đề xuất này nhằm giúp người dùng xem được danh sách các ứng dụng đã cài đặt có lưu trữ ít nhất một Protected App Signal hay một đối tượng tuỳ chỉnh.
• Người dùng có thể chặn và xoá các ứng dụng khỏi danh sách này. Thao tác chặn và xoá sẽ thực hiện những việc sau:
  • Xoá tất cả Protected App Signals và đối tượng tuỳ chỉnh được liên kết với ứng dụng.
  • Ngăn các ứng dụng lưu trữ Protected App Signals và đối tượng tuỳ chỉnh mới
• Người dùng có thể đặt lại hoàn toàn Protected App Signals và Protected Audience API. Khi điều này xảy ra, mọi Protected App Signals và đối tượng tuỳ chỉnh hiện có trên thiết bị sẽ bị xoá.
• Người dùng có thể chọn hoàn toàn không sử dụng Hộp cát về quyền riêng tư trên Android, bao gồm cả Protected App Signals API và Protected Audience API. Trong trường hợp này, Protected App Signals API và Protected Audience API sẽ trả về một thông báo ngoại lệ tiêu chuẩn: SECURITY_EXCEPTION.

Quyền cho ứng dụng và quyền kiểm soát

Đề xuất này nhằm cung cấp cho các ứng dụng quyền kiểm soát Protected App Signals:

• Ứng dụng có thể quản lý các mối liên kết với Protected App Signals.
• Ứng dụng có thể cấp cho nền tảng công nghệ quảng cáo bên thứ ba các quyền quản lý Protected App Signals thay cho ứng dụng.

Kiểm soát nền tảng công nghệ quảng cáo

Đề xuất này trình bày các cách để các công nghệ quảng cáo kiểm soát Protected App Signals:

• Tất cả công nghệ quảng cáo đều phải đăng ký bằng Hộp cát về quyền riêng tư và cung cấp miền "site" hoặc "origin" khớp với tất cả URL cho Protected App Signals.
• Các công nghệ quảng cáo có thể hợp tác với các ứng dụng hoặc SDK để cung cấp mã xác minh dùng để xác minh việc tạo Protected App Signals. Khi quy trình này được uỷ quyền cho một đối tác, việc tạo Protected App Signal có thể được định cấu hình để yêu cầu công nghệ quảng cáo xác nhận.