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

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

Đề xuất này phải tuân theo quy trình đăng ký Hộp cát về quyền riêng tư và chứng thực. Để biết thêm thông tin về quy trình chứng thực, vui lòng tham khảo vào đường liên kết chứng thực được cung cấp. Các nội dung 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:

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 tự xác định cho mỗi ứng dụng, chẳng hạn như ứng dụng lượt cài đặt, lượt mở lần đầu, hành động của người dùng (lên cấp trong trò chơi, thành tích), mua hàng hoặc thời gian trong ứng dụng. Tín hiệu được ghi và lưu trữ trên để bảo vệ khỏi 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 đã cho trong một Phiên đấu giá được bảo vệ chạy trong một môi trường an toàn.
Ad Selection API: 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 các đề xuất quảng cáo, chạy suy luận, tính toán giá thầu và tính điểm để chọn chiến thắng quảng cáo sử dụng cả Protected App Signals và thông tin ngữ cảnh theo thời gian thực do nhà xuất bản cung cấp.

Biểu đồ minh hoạ quy trình cài đặt ứng dụng bằng các tín hiệu được bảo vệ — Sơ đồ quy trình cho thấy Protected App Signals và quy trình lựa chọn quảng cáo trong Hộp cát về quyền riêng tư trên Android.

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 ứ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 cách sử dụng Protected App Signals API. Những sự kiện này được lưu trữ trong những thiết bị được bảo vệ tương tự như Đối tượng tuỳ chỉnh, và được mã hoá trước khi được gửi ra khỏi thiết bị để 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 bằng cơ chế bảo mật và chế độ kiểm soát quyền riêng tư có thể giải mã chúng để đặ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 ở chế độ nền trong Android thực thi logic này để thực hiện mã hoá trên thiết bị để tạo tải trọng Protected App Signals mà sau đó có thể được dùng theo thời gian thực để lựa chọn quảng cáo trong quá trình Phiên đấu giá. Tải trọng được lưu trữ an toàn trên thiết bị cho đến khi được gửi cho một phiên đấu giá.
Lựa chọn quảng cáo: Để chọn quảng cáo phù hợp cho người dùng, 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 một 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 Tín hiệu ứng dụng 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à giá thầu thế hệ mới). Tương tự như Protected Audience, người mua gửi quảng cáo đến 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 sở thích của người dùng. Những tính năng này được dùng để so khớp 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: Thuộc tính người bán quảng cáo tính điểm logic tính điểm tuỳ chỉnh 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 quay lại ứng dụng để kết xuất.
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

	Bản dùng thử cho nhà phát triển			Beta
Tính năng	Q4 2023	Q1 2024	Q2 2024	Q3 2024
Các API Tuyển chọn tín hiệu	Các API lưu trữ trên thiết bị	Logic của hạn mức bộ nhớ trên thiết bị Thông tin cập nhật hằng ngày về logic tuỳ chỉnh trên thiết bị	Không áp dụng	Dành cho các thiết bị 1% T+
Máy chủ truy xuất quảng cáo trong TEE	MVP	Có trên GCP Hỗ trợ việc sản xuất K UDF hàng đầu	Có trên AWS Hoạt động gỡ lỗi, chỉ số và giám sát được đồng ý
Dịch vụ suy luận trong TEE Hỗ trợ chạy các mô hình học máy và sử dụng các mô hình này để đặt giá thầu trong TEE	Đang phát triển	Có trên GCP Có thể triển khai và tạo nguyên mẫu cho các mô hình học máy tĩnh bằng Tensorflow và PyTorch	Có trên AWS Triển khai mô hình chính thức cho các mô hình Tensorflow và PyTorch Đo từ xa, Gỡ lỗi được đồng ý và Giám sát
Hỗ trợ đặt giá thầu và đấu giá trong TEE	Có trên GCP	Tích hợp truy xuất quảng cáo PAS-B&A và TEE (với phương thức mã hoá gRPC và TEE<>TEE) Hỗ trợ truy xuất quảng cáo thông qua đường dẫn theo bối cảnh (bao gồm dịch vụ hỗ trợ B&A<>K/V trên TEE)	Có trên AWS Báo cáo gỡ lỗi Hoạt động gỡ lỗi, chỉ số và giám sát được đồng ý

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. Một ứ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ư 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 được gửi ra khỏi thiết bị để chỉ tính năng Đặt giá thầu và Phiên đấu giá các dịch vụ chạy trong Môi trường thực thi đáng tin cậy có khả năng bảo mật phù hợp và chế độ kiểm soát quyền riêng tư có thể giải mã mã đó cho mục đích đặt giá thầu và tính điểm quảng cáo. Tương tự như Custom Audience API (API Đối tượng tuỳ chỉnh), không thể đọc hoặc kiểm tra các tín hiệu được lưu trữ trên thiết bị theo ứng dụng hoặc SDK; không có API để đọc giá trị tín hiệu và các API nhằm tránh làm rò rỉ sự hiện diện của các 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 chúng thêm các tính năng kỹ thuật theo thời gian thực trong quá trình Phiên đấu giá được bảo vệ đang chạy trong 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() đưa ra yêu cầu GET đến URI nhất định để truy xuất danh sách cập nhật để áp dụng cho bộ nhớ tín hiệu cục bộ. Điểm cuối URL, thuộc sở hữu của thì người mua 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ữ. Lựa chọn này có thể hữu ích, chẳng hạn như để đặt mã thử nghiệm cho người dùng cụ thể và tránh ghi đè mã thử nghiệm nếu mã đó đã có do một ứng dụng khác đặt.
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 thời gian loạt phim. 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 nên giá trị này sẽ tự động được biế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 thực hiện và trình 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ị.

Hình minh hoạ quy trình lựa chọn quảng cáo. — Quy trình lựa chọn quảng cáo trong Hộp cát về quyền riêng tư trên Android.

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

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.
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.
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.
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 giá thầu của bên mua.
Thực thi logic tính điểm của bên bán.
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) 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 ngữ 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 để đưa vào yêu cầu sẽ được gửi đến Phiên đấu giá được bảo vệ bằng lệnh gọi getAdSelectionData. Đây là cùng một API được dùng cho quy trình tái tiếp thị và được mô tả trong mục Đặt giá thầu và Đề xuất Tích hợp 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 (cho 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 người mua tín hiệu)
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.

Hình minh hoạ logic thực thi lựa chọn quảng cáo của bên mua. — Logic thực thi lựa chọn quảng cáo của bên mua trong Hộp cát về quyền riêng tư trên Android.

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.

Dịch vụ BuyerFrontEnd nhận được yêu cầu quảng cáo.
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(), Loại chiến dịch này tạo một yêu cầu để nhận được k đề xuất hàng đầu từ hoạt động Truy xuất quảng cáo Dịch vụ. Dịch vụ đặt giá thầu sẽ gửi yêu cầu này đến mục truy xuất đã định cấu hình điểm cuối máy chủ.
Dịch vụ truy xuất quảng cáo chạy UDF getCandidateAds(), lọc xuống tập hợp k quảng cáo đề xuất hàng đầu, được gửi đến đặt giá thầu.
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.
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ể:

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).
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ụ: nhúng theo ngữ cảnh được truyền đến UDF trong per_buyer_signals.
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.
Để đư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.
Tín hiệu bối cảnh auction_signals (cho thông tin về phiên đấu giá) và buyer_signals (cho người mua tín hiệu).

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 dự đoán truy xuất nó sẽ thực hiện lệnh gọi dựa trên dịch vụ suy luận theo cách sử dụng và được nhúng riêng tư để 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:

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.
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ị.
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.
Tìm nạp mục nhúng đặt giá thầu nếu các mục nhúng từ dịch vụ khoá-giá trị đang cần thiết bằng mã đặt giá thầu để đưa ra dự đoán tại thời điểm đặt giá thầu, chúng có thể 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 tín hiệu dành riêng cho phiên đấu giá đầu vào.
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 nhúng không riêng tư đều được cụ thể hoá từ máy chủ của họ 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 thị: điểm cuối để hiển thị mẫu quảng cáo.
- Siêu dữ liệu: siêu dữ liệu quảng cáo dành riêng cho công nghệ quảng cáo, phía bên mua Ví dụ: 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 dữ liệu không bắt buộc các mục nhúng được dùng khi cần phân tích mô hình để chạy suy luận trong khi đặ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 như các mục nhúng bổ sung hoặc tín hiệu spam sẽ được sử 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 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ác tính năng này có thể được sử dụng 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à:

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).
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ư.
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ể 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 trong cùng một mã như cho quy trình tái tiếp thị của Protected Audience. Để biết chi tiết, hãy xem Cấu hình Đặt giá thầu và Phiên đấu giá. Mã đặt giá thầu sẽ là có sẵn ở cùng một vị trí bộ nhớ trên đám mây của tài khoản được sử 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ư báo cáo Protected Audience đề xuất (ví dụ: reportImpression(), kích hoạt nền tảng để gửi báo cáo của người bán và người mua).

Một trường hợp sử dụng phổ biến đối với việc 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 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ố người dùng .

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

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

Về mặt kỹ thuật, quy trình này hoạt động như sau:

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

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

Để nền tảng thực thi các yêu cầu ngày càng nghiêm ngặt về quyền riêng tư, các 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 các tải trọng đầu ra bằng cách cung cấp một tệp JSON giản đồ. Giản đồ đó sẽ do nền tảng xử lý và sẽ được giữ bí mật bởi tính năng Đặt giá thầu và dịch vụ Phiên đấu giá bằng cùng cơ chế với 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 đó. Chiến lược phát hành đĩa đơn Tệp CDDL sẽ bao gồm một tập hợp các loại đối tượng được hỗ trợ (ví dụ: các tính năng là boolean, số nguyên, nhóm, v.v.). Cả tệp CDDL và giản đồ đã cung cấp sẽ được tạo phiên bản.

Ví dụ: tải trọng đầu ra bao gồm một tính năng boolean duy nhất tiếp theo là tính năng nhóm 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
        }
      ]
    }
  ]
}

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

Xây dựng 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(). Sau khi tích hợp, các công nghệ quảng cáo sẽ tạo tải trọng của mình trong Định dạng JSON. Tải trọng đầu ra này sẽ được đưa vào báo cáo giành chiến thắng của người mua cho truyền dữ liệu đến máy chủ công nghệ quảng cáo.

Phương án thay thế cho thiết kế này là tính toán vectơ đi ra trong reportWin() thay vì generateBid(). Mỗi công cụ đều có cả ưu điểm lẫn khuyết điểm và chúng tôi sẽ hoàn thiện quyết định này 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 này sẽ xác thực mọi tải trọng đầu ra do công nghệ quảng cáo tạo ra. Xác nhận kết quả đảm bảo rằng giá trị đối tượng là hợp lệ với loại của chúng, đáp ứng các giới hạn về kích thước, và rằng kẻ xấu không cố gắng đánh bại các chế độ kiểm soát quyền riêng tư bằng cách đóng gói thông tin bổ sung vào các tải trọng đầu ra của chúng.

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

Chúng tôi sẽ cung cấp một API JavaScript cho các công nghệ quảng cáo để đảm bảo tải trọng đầu ra mà chúng 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ể nào sẽ vượt qua quy trình xác thực nền tảng. Phải thực hiện xác thực thực tế trong nền tảng để bảo vệ khỏi UDF generateBid() độc hại.

Độ nhiễu của tải trọng đầu ra

Nền tảng sẽ làm nhiễu 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 tiếng ồn ban đầu sẽ là 1% và giá trị này có thể tăng lên theo thời gian. Chiến lược phát hành đĩa đơn nền tảng sẽ không cho biết liệu có trọng tải đầu ra cụ thể hay không đã bị ồn ào.

Phương thức gây nhiễu là:

Nền tảng sẽ tải định nghĩa giản đồ cho tải trọng đầu ra.
1% tải trọng đầu ra sẽ được chọn để gây nhiễu.
Nếu bạn không chọn tải trọng đầu ra, thì toàn bộ giá trị ban đầu sẽ được giữ lại.
Nếu tải trọng đầu ra được chọn, giá trị của mỗi tính năng sẽ được thay thế bằng một giá trị giá trị hợp lệ ngẫu nhiên cho loại đối tượng đó (ví dụ: 0 hoặc 1 cho tính năng 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 có nhiễu đã được xác thực sẽ được đưa vào các đối số để 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 phần quyền riêng tư ranh giới của huấn luyện mô hình. Tải trọng đầu ra sẽ ở định dạng dây.

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à tải trọng đầu ra có sẵn trên GitHub.

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

Kích thước của tải trọng đầu ra tính bằng bit giúp cân bằng giữa việc sử dụng phần mềm tiện ích và giảm thiểu việc thu thập dữ liệu. Chúng tôi sẽ làm việc với ngành để xác định quy mô 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 dữ liệu đầu ra mà không bị giới hạn về kích thước bit. Dữ liệu đầu ra bổ sung mà không có giới hạn kích thước sẽ được xóa sau khi thử nghiệm hoàn tất.

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

Ban đầu, chúng tôi sẽ hỗ trợ 2 tải trọng đầu ra trong generateBid():
1. egressPayload: tải trọng đầu ra có giới hạn về kích thước mà chúng tôi đã mô tả cho đến thời điểm này 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 (có nghĩa là hệ thống sẽ luôn xoá URL đó trong quá trình xác thực).
2. temporaryUnlimitedEgressPayload: lưu lượng ra tạm thời không giới hạn theo kích thước cho các thử nghiệm kích thước. Việc định dạng, tạo và xử lý của tải trọng đầu ra này sử dụng các cơ chế tương tự như egressPayload.
Mỗi tải trọng đầu ra này sẽ có tệp JSON giản đồ riêng: egress_payload_schema.json và temporary_egress_payload_schema.json.
Chúng tôi cung cấp giao thức thử nghiệm và bộ chỉ số để xác định mô hình tiện ích ở các kích thước tải trọng đầu ra khác nhau (ví dụ: 5, 10, ... bit).
Dựa trên kết quả thử nghiệm, chúng tôi xác định kích thước của tải trọng đầu ra với khắc phục các yếu tố đánh đổi về lợi ích và quyền riêng tư.
Chúng ta sẽ thiết lập kích thước của egressPayload từ 0 bit thành kích thước mới.
Sau một khoảng thời gian di chuyển đã định, chúng tôi sẽ xoá temporaryUnlimitedEgressPayload, chỉ để lại egressPayload với kích thước mới.

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

Tiếp theo, chúng tôi sẽ giải thích về một giao thức thử nghiệm có thể có để hoàn tất quy mô của egressPayload. Mục tiêu của chúng tôi là hợp tác với các nhà sản xuất trong ngành để tìm ra quy mô phù hợp tiện ích và giảm tối đa việc thu thập dữ liệu. Cấu phần phần mềm mà các thử nghiệm này sẽ tạo ra là 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ô hình tạo ra ở kích thước đó so với thành đườ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à các nguồn dữ liệu huấn luyện là nhật ký của chúng ta và nội dung của temporaryUnlimitedegressPayload mà chúng ta nhận được khi chúng tôi thắng phiên đấu giá. Giao thức cho công nghệ quảng cáo trước hết bao gồm giao thức ngoại tuyến thử nghiệm:

Xác định kiến trúc của các mô hình mà chúng sẽ sử dụng với Protected App Tín hiệu. Ví dụ: họ cần xác định xem mình có hãy sử dụng tính năng phân tích mô hình.
Xác định chỉ số để đo lường chất lượng mô hình. Chỉ số được đề xuất là mức giảm AUC và nhật ký mất mát.
Xác định tập hợp tính năng mà các em sẽ sử dụng trong quá trình huấn luyện mô hình.
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, chạy các nghiên cứu giảm dần để xác định lợi ích đóng góp trên mỗi bit cho mỗi mà họ muốn sử dụng trong PAS. Giao thức được đề xuất cho nghiên cứu loại bỏ là:
1. Huấn luyện mô hình với tất cả các tính năng và tiện ích đo lường; đây là đường cơ sở để so sánh.
2. Đối với mỗi đối tượng dùng để tạo đường cơ sở, hãy huấn luyện mô hình bằng tất cả tính năng ngoại trừ tính năng đó.
3. Đo lường tiện ích thu được. Chia delta cho kích thước của đối tượng tính bằng bit; đây là tiện ích dự kiến trên mỗi bit của tính năng đó.
Xác định quy mô tải trọng huấn luyện mà bạn quan tâm để thử nghiệm. T4 đề xuất [5, 10, 15, ..., size_of_all_training_features_for_baseline] một chút. Mỗi kích thước này đại diện cho một kích thước có thể có cho egressPayload mà thử nghiệm sẽ đánh giá.
Đối với mỗi kích thước có thể có, hãy chọn một nhóm tính năng nhỏ hơn hoặc bằng giúp tối đa hoá tiện ích mỗi bit, dựa trên kết quả nghiên cứu loại bỏ.
Huấn luyện mô hình cho từng quy mô có thể có và đánh giá sự hữu ích của mô hình đó như một tỷ lệ phần trăm lợi ích của mô hình cơ sở được huấn luyện về tất cả tính năng.
Vẽ kết quả lên biểu đồ, trong đó trục x là kích thước của khoá đào tạo tải trọng tính theo bit và trục y là tỷ lệ phần trăm doanh thu được tạo ra mô hình đó 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 từ 5 đến 8 trong thử nghiệm lưu lượng truy cập trực tiếp bằng cách sử dụng tính năng dữ liệu được gửi qua temporaryUnlimitedEgressPayload. Công nghệ quảng cáo có thể chọn chia sẻ kết quả thử nghiệm lưu lượng truy cập trực tiếp và ngoại tuyến bằng 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 cho những thử nghiệm này, cũng như tiến trình đặt quy mô là egressPayload so với giá trị thu được, nằm ngoài phạm vi của tài liệu này và sẽ có bản cập nhật sau.

Các 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 đi ra, bao gồm:

Cả egressPayload và temporaryUnlimitedEgressPayload sẽ bị nhiễu.
Để 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 Ứng dụng được bảo vệ hiện có Các tín hiệu và đối tượng tuỳ chỉnh trên thiết bị này 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 quyền quản lý Protected App Signals thay mặt 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ông nghệ quảng cáo có thể hợp tác với ứng dụng hoặc SDK để cung cấp mã xác minh được 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.