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ý và chứng thực Hộp cát về quyền riêng tư. Để biết thêm thông tin về các 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ó đượ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 trên mỗi ứng dụng, chẳng hạn như lượt cài đặt ứng dụng, lần mở đầu tiên, hành động của người dùng (lên 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ị để chống 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 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ôi trường thực thi đáng tin cậy (TEE), trong đó 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 quảng cáo "giành chiến thắng" bằng cách sử dụng cả Tín hiệu ứng dụng được bảo vệ và thông tin bối 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 hiển thị quy trình lựa chọn quảng cáo và Tín hiệu của ứng dụng được bảo vệ 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 dành cho thiết bị di động, công nghệ quảng cáo sẽ chọn lọ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 thông qua Protected App Tín hiệu API. Những 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, và được mã hoá trước khi gửi ra khỏi thiết bị để chỉ các dịch vụ Đặt giá thầu và Phiên đấu giá đang chạy trong Môi trường thực thi đáng tin cậy có chế độ 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ã các sự kiện đó để đặ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. Tác vụ chạy trong nền Android sẽ thực thi logic này để mã hoá trên thiết bị nhằm tạo ra tải trọng Tín hiệu ứng dụng được bảo vệ mà sau này có thể dùng theo thời gian thực cho việc lựa chọn quảng cáo trong Phiên đấu giá được bảo vệ. 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 sẽ gửi tải trọng đã mã hoá của Tín hiệu ứng dụng được bảo vệ 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ị Tín hiệu của ứng dụng được bảo vệ 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 yêu cầu quảng cáo Open-RTB) để thiết kế các tính năng dành cho việc 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 gửi quảng cáo cho người bán để được tính điểm cuối cùng trong Phiên đấu giá được bảo vệ.
- Truy xuất quảng cáo: Người mua sử dụng Tín hiệu của ứng dụng được bảo vệ và dữ liệu bối cảnh do nhà xuất bản cung cấp cho các tính năng kỹ thuật phù hợp với mối quan tâm của người dùng. Các tính năng này được dùng để khớp với 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 tính điểm quảng cáo do Người mua tham gia gửi và chọn quảng cáo chiến thắng để gửi lại ứng dụng để 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

	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. Ứng dụng hoặc SDK tích hợp có thể lưu trữ hoặc xoá Tín hiệu của ứng dụng được bảo vệ 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). Tín hiệu của ứng dụng được bảo vệ được lưu trữ an toàn trên thiết bị, đồng thời được mã hoá trước khi 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 có chế độ 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 cho quảng cáo đặt giá thầu và tính điểm. Tương tự như Custom Audience API (API Đối tượng tuỳ chỉnh), các ứng dụng hoặc SDK không thể đọc hoặc kiểm tra 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à 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.
một API JavaScript nhằm xử lý các tín hiệu ổn định nhằm chuẩn bị cho các tín hiệu đó cho kỹ thuật thêm tính năng theo thời gian thực trong một 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 URI và truy xuất danh sách nội dung cập nhật tín hiệu. Để minh hoạ, fetchSignalUpdates() sẽ gửi yêu cầu GET tới URI nhất định để truy xuất danh sách nội dung cập nhật nhằm á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ữ. Ví dụ: tuỳ chọn này có thể hữu ích khi đặt mã thử nghiệm cho một người dùng nhất định và tránh ghi đè mã này nếu một ứng dụng khác đã đặt mã này.
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 chuyển đổi thành 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 yêu cầu tìm nạp và phản hồi yêu cầu ("trang web" hoặc "nguồn gốc" 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) 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 bối cảnh có liên quan từ nhà xuất bản và tải trọng đã mã hoá cho mỗi người mua cần đư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 dùng cho quy trình tái tiếp thị như đã mô tả trong đề xuất Tích hợp chiến lược đặ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.

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 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 UDF có tên là prepareDataForAdRetrieval(), sẽ tạo một yêu cầu để có được k đề xuất hàng đầu từ Dịch vụ truy xuất quảng cáo. Dịch vụ đặt giá thầu 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.
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 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 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ụ: nội dung 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.
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 lượt 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ụ dự đoán bằng các tính năng trên và nhận 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:

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 nhúng giá thầu: Nếu cần 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ì bạn có thể truy xuất các nhúng 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:

Tính năng 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 nhúng không công khai đều được cụ thể hoá từ 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 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ụ: 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 nội dung nhúng không bắt buộc được dùng khi cần phân tích mô hình để chạy dự đoán trong quá trình đặt giá thầu.
Tín hiệu bổ sung: Dịch vụ truy xuất quảng cáo có thể bao gồm cả thông tin bổ sung như các lượt nhúng bổ sung hoặc tín hiệu rác 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:

Featurization: chuyển đổi tín hiệu thành các tính năng để sử dụng trong quá trình dự đoá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ị dự đoán với các dữ liệu đầ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. Bạn có thể sử dụng các tính năng này trong quá trình dự đoán để dự đoán những thông tin như tỷ lệ 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à thông tin 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 tương tự như 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ã được dùng để tái tiếp thị.

Báo cáo

Đề xuất này sử dụng các API báo cáo giống 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 của người bán và người mua).

Một trường hợp sử dụng phổ biến để báo cáo bên mua là lấy dữ liệu huấn luyện cho các mô hình được 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ể để xuất dữ liệu cấp sự kiện từ nền tảng đến các 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 sẽ đ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 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 bên 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.

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

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

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 ứng dụng này tạo tải trọng đầu ra mong muốn.
Nền tảng này sẽ xác thực tải trọng đầu ra dựa trên giản đồ và thực thi các giới hạn về kích thước.
Nền tảng này sẽ gây nhiễu cho tải trọng đầu ra.
Tải trọng đầu ra được đưa vào báo cáo giành chiến thắng ở định dạng dây, nhận trên các máy chủ công nghệ quảng cáo, được giải mã và dùng để huấn luyện mô hình.

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

Để nền tảng thực thi các yêu cầu ngày càng tăng về quyền riêng tư, tải trọng đầu ra phải được cấu trúc sao cho 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 đầ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 các dịch vụ Đặt giá thầu và Phiên đấu giá bảo mật bằng cách sử dụng các cơ chế tương tự 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 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 đối tượng là boolean, số nguyên, bộ chứa, v.v.). Cả tệp CDDL và giản đồ đã cung cấp đều 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, theo sau là tính năng nhóm có kích thước 2 sẽ trông giố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.

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

Tất cả Tín hiệu ứng dụng được bảo vệ cho một người mua nhất định đều có sẵn trong UDF generateBid(). Sau khi hoàn thiện, các công nghệ quảng cáo sẽ tạo tải trọng ở định dạng JSON. Tải trọng đầ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ơ đầu ra trong reportWin() thay vì generateBid(). Mỗi phương pháp đều có một số điểm đánh đổi và chúng tôi sẽ đưa ra quyết định này dựa trên ý kiến phản hồi trong 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. Việc xác thực đảm bảo rằng các giá trị của tính năng là hợp lệ cho các loại dữ liệu, đáp ứng các giới hạn về kích thước và đối tượng độc hại 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 tải trọng đầu ra của chúng.

Nếu tải trọng đầu ra không hợp lệ, tải trọng đầu ra sẽ tự động bị loại bỏ khỏi các dữ liệu đầu vào được gửi đến báo cáo chiến thắng. Lý do là vì 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 muốn thất bại quy trình 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 các 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. Phải thực hiện xác thực thực tế trong nền tảng để chống lại UDF generateBid() độc hại.

Tạo tiếng ồn cho tải trọng đầu ra

Nền tảng này sẽ nhiễu các tải trọng đầu ra trước khi đưa chúng vào báo cáo giành chiến thắng. Ngưỡng độ nhiễu ban đầu sẽ là 1% và giá trị này có thể tăng lên theo thời gian. Nền tảng này sẽ không cung cấp chỉ báo cho biết liệu một tải trọng đầu ra cụ thể có bị nhiễu hay không.

Phương pháp gây nhiễu là:

Nền tảng này 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 bạn chọn tải trọng đầu ra, giá trị của mỗi tính năng sẽ được thay thế bằng một giá trị hợp lệ ngẫu nhiên cho loại tính năng đó (ví dụ: 0 hoặc 1 cho một tính năng boolean).

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

Tải trọng đầu ra đã được xác thực và gây nhiễu sẽ được đưa vào các đối số tới 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 về quyền riêng tư để 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à cho tải trọng đầu ra có 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 theo bit sẽ cân bằng giữa mức sử dụng và giảm thiểu dữ liệu. Chúng tôi sẽ làm việc với các chuyên gia 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 có giới hạn kích thước bit. Dữ liệu đầu ra bổ sung mà 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 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 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à 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 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ơ chế giống 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 một giao thức thử nghiệm và bộ chỉ số để xác định phần mềm 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).
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 bằng tiện ích và sự đánh đổi chính xác về quyền riêng tư.
Chúng ta đặt 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ất định, chúng tôi sẽ xoá temporaryUnlimitedEgressPayload và chỉ để lại egressPayload với kích thước mới.

Chúng tôi đang nghiên cứu 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 tệp từ 0 bit). Những thông tin chi tiết đó – cùng với thông tin bổ sung như giao thức thử nghiệm, thời gian thử nghiệm và thời gian xoá temporaryUnlimitedEgressPayload – sẽ được đưa vào nội dung cập nhật sau này.

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 xuất ra, bao gồm:

Cả egressPayload và temporaryUnlimitedEgressPayload sẽ bị nhiễu.
Đối với việc giảm thiểu và bảo vệ dữ liệu, temporaryUnlimitedEgressPayload sẽ chỉ được cung cấp trong thời gian tiến hành thử nghiệm kích thước. Trong thời gian này, 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ả Tín hiệu của ứng dụng được bảo vệ 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 Tín hiệu ứng dụng được bảo vệ 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ý tín hiệu của Ứng dụng được bảo vệ 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ô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 dùng để xác minh việc tạo Tín hiệu của ứng dụng được bảo vệ. 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.