Dịch vụ Đặt giá thầu và Phiên đấu giá

Trong phần đề xuất Protected Audience ban đầu, hoạt động đặt giá thầu và phiên đấu giá cho nhu cầu quảng cáo tái tiếp thị được thực thi trên thiết bị. Việc này có thể đòi hỏi các yêu cầu về tính toán không thực thi được trên các thiết bị có khả năng xử lý hạn chế hoặc có thể quá chậm để chọn và hiển thị quảng cáo do độ trễ mạng.

Đề xuất về dịch vụ Đặt giá thầu và Phiên đấu giá (B&A) đề ra cách cho phép thực hiện việc tính toán Protected Audience trên các máy chủ đám mây trong môi trường thực thi đáng tin cậy (TEE), thay vì chạy trên thiết bị của người dùng. Đề xuất B&A nhằm hỗ trợ một quy trình hợp nhất để xem xét nhu cầu quảng cáo tái tiếp thị và theo bối cảnh. Việc chuyển hoạt động tính toán sang máy chủ có thể giúp tối ưu hoá phiên đấu giá Protected Audience bằng cách giải phóng chu kỳ tính toán và băng thông mạng cho thiết bị.

Google sẽ cung cấp các thành phần của B&A và những thành phần này sẽ hoạt động dưới dạng nguồn mở. Các công nghệ quảng cáo được quan tâm có thể lưu trữ bản sao của riêng chúng thông qua các nhà cung cấp dịch vụ đám mây công khai được hỗ trợ. Bạn có thể đọc thêm về đề xuất B&A trên GitHub. Xin lưu ý rằng ngày trong tài liệu đó phản ánh thời điểm triển khai Chrome, đồng thời chúng tôi sẽ công bố thêm thông tin về việc tích hợp với Android trong tương lai. Tài liệu này đóng vai trò như phần giới thiệu về B&A và các API mới mà Android sẽ cung cấp để tương tác với B&A. Chúng tôi sẽ đăng thêm thông tin kỹ thuật về cách sử dụng các API mới này trong những nội dung cập nhật sau này.

Vị trí phù hợp cho các dịch vụ B&A

B&A cung cấp thêm một lựa chọn để chạy phiên đấu giá trong các máy chủ đáng tin cậy do công nghệ quảng cáo sở hữu. Những máy chủ này chạy một tệp nhị phân nguồn mở do Google cung cấp. Dữ liệu người dùng vẫn tồn tại trên thiết bị và Google sẽ cung cấp các API để di chuyển dữ liệu đó sang TEE một cách an toàn. Tìm hiểu thêm về chiến lược mã hoá bên dưới.

Điều này có nghĩa là một số phần của quy trình đấu giá diễn ra trên thiết bị và một số phần khác trên đám mây. Từ góc độ của DSP, các đối tượng tuỳ chỉnh (bao gồm cả quảng cáo đề xuất cho các chiến dịch tái tiếp thị) vẫn được quản lý trên thiết bị bằng cách sử dụng cùng API quản lý đối tượng tuỳ chỉnh như khi phiên đấu giá chạy trên thiết bị. Từ góc độ SSP, các yêu cầu vẫn được kích hoạt trên thiết bị và tài liệu này mô tả các API mới sẽ được dùng. Đối với tất cả các bên, việc báo cáo kết quả của phiên đấu giá vẫn sẽ bắt đầu từ thiết bị, sau khi lệnh gọi B&A hoàn tất.

Điểm khác biệt chính nằm ở vị trí thực thi logic đặt giá thầu, tính điểm và tạo URL báo cáo. Thay vì chạy logic đặt giá thầu, đấu giá và báo cáo trên thiết bị, logic generateBid(), scoreAd(), reportResult() và reportWin() sẽ được thực thi trong TEE. Logic đặt giá thầu của người mua và logic tính điểm của người bán được thực thi trong môi trường B&A của riêng họ, ở giữa quy trình đấu giá Protected Audience:

Hình minh hoạ thể hiện quy trình đấu giá của Protected Audience và vị trí đặt giá thầu cũng như phiên đấu giá phù hợp.
Quy trình đấu giá Protected Audience

Mã hoá dữ liệu

Với B&A, thông tin về Protected Audience như đối tượng tuỳ chỉnh và số tiền đặt giá thầu sẽ được chuyển từ thiết bị này qua máy chủ công nghệ quảng cáo của người bán đến máy chủ công nghệ quảng cáo của người mua rồi chuyển về thiết bị. Do đó, nền tảng này sẽ mã hoá dữ liệu được chuyển đến các dịch vụ Protected Audience và chỉ có thể giải mã bằng các dịch vụ đã được chứng thực. Đọc thêm về các chiến lược mã hoá trên GitHub.

Cấu trúc và quy trình đấu giá

Đề xuất này bao gồm nhu cầu về một số thành phần mới được nêu chi tiết trên GitHub, bao gồm cả luồng dữ liệu từ thiết bị đến B&A.

Hình minh hoạ thể hiện quy trình đấu giá Protected Audience theo bối cảnh hợp nhất, sẽ được mô tả trong phần tiếp theo.
Theo bối cảnh hợp nhất và Quy trình đấu giá Protected Audience với các dịch vụ đặt giá thầu và phiên đấu giá.

Ở cấp độ cao, luồng dữ liệu được mô tả như sau:

  1. Trên thiết bị, người bán thu thập thông tin từ Protected Audience bằng cách sử dụng API getAdSelectionData.
  2. SDK trên thiết bị gửi một yêu cầu đến dịch vụ Quảng cáo của người bán. Yêu cầu này bao gồm tải trọng theo bối cảnh và ProtectedAudienceInput đã mã hoá.
  3. Dịch vụ Quảng cáo của người bán gửi yêu cầu đến dịch vụ đặt giá thầu theo thời gian thực (RTB) của người mua chạy bên ngoài TEE để lấy quảng cáo theo bối cảnh đề xuất, sau đó tính điểm và chọn quảng cáo theo bối cảnh.
  4. Dịch vụ quảng cáo của Người bán gửi yêu cầu tới dịch vụ SellerFrontEnd của họ. Dịch vụ này chạy trong TEE.
  5. Dịch vụ SellerFrontEnd gửi yêu cầu có dữ liệu cụ thể của người mua đến các dịch vụ BuyerFrontEnd.
  6. Người mua sử dụng dịch vụ Khoá/Giá trị và dịch vụ Đặt giá thầu của riêng mình để tạo giá thầu cho các đề xuất quảng cáo có nguồn gốc từ thiết bị đối với mọi đối tượng tuỳ chỉnh được cân nhắc cho hoạt động tái tiếp thị.
  7. Dịch vụ SellerFrontEnd đọc từ dịch vụ Khoá/Giá trị và tính điểm cho quảng cáo đề xuất. Kết quả sẽ được mã hoá và trả về dịch vụ Quảng cáo của người bán.
  8. Dịch vụ Quảng cáo của người bán sẽ trả về kết quả chiến thắng được mã hoá và kết quả theo bối cảnh cho SDK trên thiết bị (không bắt buộc).
  9. Trên thiết bị, người bán truy xuất quảng cáo chiến thắng bằng cách sử dụng API processAdSelectionResult. API này sẽ giải mã phản hồi từ dịch vụ Quảng cáo của người bán.

Bạn có thể xem nội dung mô tả chi tiết về từng bước và cách dữ liệu được mã hoá trên GitHub. Mã cho các thành phần này sẽ được cung cấp qua nguồn mở. Mã được cung cấp sẽ xử lý việc liên kết các yêu cầu từ dịch vụ SellerFrontEnd đến các dịch vụ BuyerFrontEnd.

Triển khai đám mây

Công nghệ quảng cáo sẽ triển khai các dịch vụ B&A cho một nền tảng đám mây công khai được hỗ trợ. Những hoạt động triển khai này do công nghệ quảng cáo quản lý. Chúng sẽ chịu trách nhiệm xác định Mục tiêu mức độ dịch vụ về khả năng sử dụng.

Chạy phiên đấu giá

Bước đầu tiên để chạy phiên đấu giá B&A là thu thập dữ liệu từ các đối tượng tuỳ chỉnh trên thiết bị và mã hoá dữ liệu đó để gửi đến các phiên đấu giá phía máy chủ. Để làm việc này, hãy sử dụng API getAdSelectionData:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Phương thức getAdSelectionData tạo dữ liệu đầu vào bắt buộc cho các thành phần B&A, chẳng hạn như BuyerInput và ProtectedAudienceInput, đồng thời mã hoá dữ liệu trước khi cung cấp kết quả cho phương thức gọi. Để ngăn rò rỉ dữ liệu trên các ứng dụng, dữ liệu này chứa thông tin của tất cả những người mua có trên thiết bị. Đọc thêm về quyết định này trong phần các cân nhắc về quyền riêng tư.

API này trả về một đối tượng AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Khi sử dụng AdSelectionData này, SDK trên thiết bị có thể gửi yêu cầu đến dịch vụ Quảng cáo của người bán bằng cách đưa dữ liệu vào yêu cầu POST hoặc PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

SDK trên thiết bị chịu trách nhiệm mã hoá dữ liệu này. Bạn nên sử dụng một giải pháp hiệu quả về không gian, chẳng hạn như gửi yêu cầu đến dịch vụ Quảng cáo của người bán dưới dạng multipart/form-data.

Sau khi bắt đầu yêu cầu, dịch vụ Quảng cáo của người bán sẽ chuyển tiếp yêu cầu này đến dịch vụ SellerFrontEnd đang chạy trong một TEE. Khi định cấu hình dịch vụ SellerFrontEnd, người bán sẽ cung cấp danh sách địa chỉ miền tương ứng với các dịch vụ BuyerFrontEnd do người mua vận hành và người bán là đối tác. Các yêu cầu sẽ được liên kết với nhiều dịch vụ BuyerFrontEnd mà người bán đã cung cấp, để người mua có thể đặt giá thầu cho các đề xuất quảng cáo mà họ đã chọn. Đối với một người mua cụ thể, B&A sẽ chỉ gửi thông tin về đối tượng tuỳ chỉnh mà người mua sở hữu để không làm rò rỉ dữ liệu giữa những người mua. Sau khi tạo giá thầu, danh sách quảng cáo đề xuất sẽ quay lại dịch vụ SellerFrontEnd mà quảng cáo chiến thắng được chọn. Cuối cùng, dịch vụ SellerFrontEnd trả về quảng cáo chiến thắng được mã hoá cho thiết bị.

Với phản hồi từ yêu cầu đối với dịch vụ Quảng cáo của người bán được trả về trên thiết bị, nền tảng này sẽ cung cấp một API mới thứ hai để giải mã kết quả và cung cấp AdSelectionOutcome, chính là đối tượng được trả về từ phiên đấu giá trên thiết bị hôm nay.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Báo cáo

URL báo cáo sẽ được tạo trong các dịch vụ B&A. Ping đến các URL đó để báo cáo lượt hiển thị và lượt tương tác cho phiên đấu giá sẽ vẫn cần được kích hoạt trên thiết bị. SDK trên thiết bị vẫn sẽ cần gọi các API reportImpression() và reportInteraction() bằng cách sử dụng AdSelectionId được tạo trong luồng B&A. Các beacon được tạo cho báo cáo tương tác và các URL tương ứng có trong phản hồi được mã hoá, vì vậy, trong quá trình giải mã phản hồi, các sự kiện và liên kết URL được lưu trữ trên thiết bị.

Những điều cần cân nhắc về quyền riêng tư

Đề xuất về Browser Bidding & Auction API (API Đặt giá thầu và Phiên đấu giá cho trình duyệt) trên GitHub mô tả cách chúng tôi cân nhắc về quyền riêng tư. Đề xuất này sử dụng các thuật ngữ của Chrome, nhưng những nguyên tắc tương tự sẽ áp dụng cho Android.

adSelectionData được mã hoá để đảm bảo rằng chỉ có PPAPI và các máy chủ đáng tin cậy mới truy cập được vào dữ liệu đang truyền. Để giảm thiểu nguy cơ rò rỉ dữ liệu do các thay đổi về kích thước adSelectionData, chúng tôi dự định tạo cùng một adSelectionData cho tất cả các lệnh gọi đến API getAdSelectionData. Điều này có nghĩa là mọi CustomAudience trên thiết bị đều được dùng để tạo adSelectionData. Chúng tôi cũng có kế hoạch hạn chế ảnh hưởng của các tham số đầu vào GetAdSelectionData đối với adSelectionData đã tạo.

Việc tạo cùng một adSelectionData cho tất cả các công nghệ quảng cáo bằng cách dùng mọi dữ liệu đấu giá trên thiết bị sẽ dẫn đến việc cần truyền tải trọng cao hơn trong mỗi lệnh gọi đến máy chủ công nghệ quảng cáo, trong khi việc này có khả năng sẽ mở ra hệ sinh thái lạm dụng các thực thể độc hại. Những mối lo ngại này được giải quyết trong phần Những điều cần cân nhắc về kích thước và Những điều cần cân nhắc về chống hành vi sai trái bên dưới.

Những điều cần cân nhắc về kích thước

SDK ứng dụng sử dụng công nghệ quảng cáo dự kiến sẽ đóng gói các byte đã mã hoá của adSelectionData thành một lệnh gọi cho các quảng cáo theo bối cảnh được gửi đến máy chủ của Người bán. Để có hiệu suất tối ưu, bạn phải tối ưu hoá kích thước của adSelectionData mà không làm ảnh hưởng đến chức năng. Chúng tôi dự định giới thiệu các hoạt động tối ưu hoá như đã đề cập trong Nội dung giải thích về hoạt động tối ưu hoá tải trọng để giảm kích thước adSelectionData. Những hoạt động tối ưu hoá này sẽ bao gồm:

  1. Thêm ad_render_id trong CustomAudience để nó được gửi bằng cách sử dụng adSelectionData thay vì dùng URI hiển thị quảng cáo và siêu dữ liệu. Công nghệ quảng cáo có thể tối ưu hoá hơn nữa bằng cách không gửi dữ liệu quảng cáo trong adSelectionData. Lựa chọn này sẽ được hỗ trợ trong CustomAudience API ở các bản phát hành sau này.
  2. Đảm bảo bạn không gửi user_bidding_signals trong adSelectionData. Thay vào đó, công nghệ quảng cáo có thể tìm nạp user_bidding_signals từ máy chủ Khoá/Giá trị.
  3. Cho phép người mua ưu tiên CustomAudience.
  4. Cho phép người mua chỉ định mức độ ưu tiên của người bán.
  5. Tạo adSelectionData trong một số bộ chứa cố định để hạn chế tình trạng rò rỉ bit trong khi giảm kích thước tải trọng.

Việc tối ưu hoá kích thước sẽ được thực hiện trong khi vẫn tuân thủ các vấn đề phát sinh khi cân nhắc về quyền riêng tư.

Những điều cần cân nhắc về chống hành vi sai trái

Như đã đề cập trong phần Những điều cần cân nhắc về quyền riêng tư, adSelectionData được tạo bằng cách sử dụng tất cả dữ liệu người mua trên thiết bị.

Việc này mở ra hệ sinh thái cho các thực thể độc hại tiềm ẩn có thể thêm dữ liệu người mua gian lận làm giảm hiệu suất, nâng tải trọng để tăng chi phí và nhiều vấn đề khác.

Để chống lại hành vi lạm dụng adSelectionData, chúng tôi sẽ giới thiệu các biện pháp sau

  • Cho phép CustomAudience chỉ định rõ những người bán được phê duyệt và mức độ ưu tiên của người bán
  • Cho phép SSP chỉ định người mua, mức ưu tiên của người mua, hạn mức cho mỗi người mua trong tải trọng đã tạo
  • Cung cấp cơ chế cho SSP để xác định số người mua tối đa cho mỗi lệnh gọi hoặc kích thước tối đa cho mỗi người mua.

Những biện pháp này được thiết kế để cho phép các công nghệ quảng cáo xác định công nghệ quảng cáo khác mà chúng có thể cộng tác và đặt giới hạn chấp nhận được đối với tải trọng adSelectionData mà chúng cần xử lý. Chúng tôi đề xuất cho phép người bán chỉ định danh sách người mua và mức độ ưu tiên trong một lệnh gọi riêng. Thông số kỹ thuật này sẽ không đổi trong một khoảng thời gian để tránh làm lộ thêm dữ liệu về người dùng qua các lệnh gọi lặp lại.

Các biện pháp giảm thiểu nêu trên đang được thảo luận và sẽ phát triển theo thời gian. Như đã đề cập trước đó, tất cả các biện pháp giảm thiểu dùng trong trường hợp chống hành vi sai trái và hạn chế về kích thước đều phải tuân thủ những điều cần cân nhắc về quyền riêng tư.