Cải thiện độ trễ của phiên đấu giá Protected Audience API

Mọi người đều nên đảm bảo Protected Audience API hoạt động hiệu quả:

  • Những người duyệt web muốn trang web tải nhanh. Điều này có nghĩa là nhà phát triển nên xây dựng bằng Protected Audience API một cách hiệu quả để không sử dụng quá mức các tài nguyên thiết bị bị hạn chế, chẳng hạn như tài nguyên điện toán hoặc mạng cần thiết để tải trang web và quảng cáo được nhúng.
  • Nhà xuất bản muốn trang web của họ tải nhanh, mang đến cho người dùng trải nghiệm hiệu quả và thích ứng. Nhà xuất bản cũng muốn quảng cáo hiệu quả để tối đa hoá doanh thu.
  • Nhà quảng cáo và công nghệ quảng cáo muốn quảng cáo của họ hiển thị nhanh chóng để mang lại giá trị hữu ích nhất.

Tài liệu này trình bày một số phương pháp hay nhất để triển khai Protected Audience API, nhằm đảm bảo trang web của bạn hoạt động hiệu quả nhất.

Các phương pháp hay nhất dành cho người mua (người đặt giá thầu)

Để đảm bảo bạn đang tối ưu hoá hiệu quả phiên đấu giá Protected Audience API, hãy làm theo các phương pháp hay nhất sau.

Ít chủ sở hữu nhóm đối tượng có cùng mối quan tâm hơn

Để bảo vệ bên đặt giá thầu Protected Audience API theo cách tương tự như cách trình duyệt bảo vệ các nguồn gốc khác nhau trên web bằng cách sử dụng tính năng phân tách trang web, trình duyệt sử dụng các tài nguyên tốn kém (chẳng hạn như các quy trình hệ điều hành) để bảo vệ từng chủ sở hữu nhóm mối quan tâm.

Để giảm thiểu mức chi tiêu cho những tài nguyên rất tốn kém này, điều quan trọng là bạn phải có ít chủ sở hữu nhóm mối quan tâm nhất. Tránh việc các nhóm mối quan tâm khác nhau thuộc quyền sở hữu của nhiều miền con. Ví dụ: nếu adtech.example có các nhóm mối quan tâm thuộc sở hữu của cats.adtech.example và dogs.adtech.example, thì trình duyệt có thể sẽ sử dụng hai quy trình riêng biệt để chạy các tập lệnh đặt giá thầu.

Ít nhóm mối quan tâm đặt giá thầu hơn

Trình duyệt phải thực hiện các bước thiết lập và chuẩn bị quan trọng trước khi gọi tập lệnh generateBid() của người mua, chẳng hạn như thiết lập môi trường thực thi JavaScript mới và phân tích cú pháp cũng như tải mã generateBid().

  • Nhóm mối quan tâm đại diện cho những người dùng không phải là mục tiêu hiện tại của một chiến dịch quảng cáo đang hoạt động phải có danh sách mẫu quảng cáo trống. Điều này ngăn Protected Audience API thực thi generateBid() cho các nhóm đối tượng có cùng mối quan tâm không có quảng cáo liên quan.
  • Việc kết hợp các nhóm mối quan tâm tương tự sẽ làm giảm số lần phải chạy generateBid(). Bạn có thể sử dụng thuộc tính userBiddingSignals của nhóm mối quan tâm để lưu trữ siêu dữ liệu bổ sung về người dùng. Vì vậy, việc có ít nhóm mối quan tâm hơn không có nghĩa là hoạt động nhắm mục tiêu sẽ kém hiệu quả hơn.
  • Protected Audience API hỗ trợ các giới hạn do người bán chỉ định về số lượng nhóm đối tượng có cùng mối quan tâm và một API để người mua chỉ định mức độ ưu tiên tương đối của các nhóm đối tượng có cùng mối quan tâm. Bạn có thể sử dụng các giới hạn này để giảm đáng kể số lượng kịch bản đặt giá thầu cần chạy.

Lọc ra các nhóm mối quan tâm khỏi hoạt động đặt giá thầu trong dịch vụ Khoá/Giá trị

Nếu có thể xác định trong máy chủ tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực rằng một số nhóm mối quan tâm nhất định không nên đặt giá thầu (ví dụ: chiến dịch bị tắt, tạm dừng hoặc hết ngân sách hoặc không nên đặt giá thầu cho nhà xuất bản cụ thể này), thì người mua có thể cho trình duyệt biết điều này bằng phản hồi priorityVector đối với hoạt động tìm nạp tín hiệu đặt giá thầu đáng tin cậy. Nếu tích vô hướng thưa thớt thu được của priorityVector và prioritySignals là âm, thì trình duyệt sẽ bỏ qua việc gọi generateBid() cho nhóm mối quan tâm này. Bạn có thể đọc thêm về cơ chế này trong phần "Lọc và ưu tiên các nhóm mối quan tâm" của nội dung giải thích.

Sử dụng lại môi trường thực thi JavaScript

Trước khi có thể thực thi generateBid(), trình duyệt phải khởi chạy một môi trường thực thi JavaScript mới. Quá trình này có thể mất một khoảng thời gian đáng kể, tương đương với khoảng thời gian mà chính generateBid() tối thiểu có thể mất để thực thi. Bạn có thể tiết kiệm thời gian này bằng cách sử dụng chế độ thực thi nhóm theo nguồn gốc hoặc ngữ cảnh đông lạnh.

Chế độ group-by-origin có thể sử dụng lại môi trường thực thi trong trường hợp các nhóm mối quan tâm được kết hợp trên cùng một nguồn gốc và có thể sẽ không yêu cầu thay đổi tập lệnh đặt giá thầu; để tìm hiểu thêm, hãy xem nội dung mô tả group-by-origin trong phần giải thích. Chế độ ngữ cảnh đã đóng băng có thể sử dụng lại tất cả môi trường thực thi, nhưng có thể yêu cầu thay đổi tập lệnh đặt giá thầu; để tìm hiểu thêm, hãy xem nội dung mô tả frozen-context trong phần giải thích.

Sử dụng lại tập lệnh đặt giá thầu

Sử dụng cùng một tập lệnh đặt giá thầu cho các nhóm mối quan tâm nếu có thể. Điều này giúp trình duyệt không phải tải xuống, phân tích cú pháp và biên dịch nhiều tập lệnh (gây ra thêm các yêu cầu mạng). Bên đặt giá thầu vẫn có thể phân biệt giá thầu dựa trên thông tin nhóm mối quan tâm (ví dụ: name hoặc userBiddingSignals) trong khi sử dụng cùng một tập lệnh.

Nếu không có tiêu đề kiểm soát bộ nhớ đệm HTTP, tập lệnh đặt giá thầu sẽ không được lưu vào bộ nhớ đệm. Chỉ định các tiêu đề thích hợp để đảm bảo tập lệnh không bị tìm nạp không cần thiết. Nếu có nhiều phiên đấu giá trên trang chạy song song, thì tập lệnh đặt giá thầu của cùng một bên đặt giá thầu sẽ được sử dụng lại nếu tập lệnh đó đã có trong bộ nhớ, bỏ qua ngữ nghĩa lưu vào bộ nhớ đệm. Nếu các phiên đấu giá chạy tuần tự, thì trình duyệt sẽ tuân thủ cơ chế lưu vào bộ nhớ đệm HTTP.

Xin lưu ý rằng trình duyệt tải tập lệnh đặt giá thầu trong thời gian đặt giá thầu (đối với generateBid()) và cũng trong thời gian báo cáo (đối với reportWin()). Nếu bạn không đặt tiêu đề kiểm soát bộ nhớ đệm, thì trình duyệt sẽ tìm nạp cùng một tập lệnh hai lần, một lần cho mỗi khoảng thời gian.

Do đó, bạn nên đặt tiêu đề kiểm soát bộ nhớ đệm trên tất cả các tập lệnh.

Sử dụng lại trustedBiddingSignalsUrls

Độ trễ mạng và mức sử dụng tài nguyên có thể rất đáng kể. Việc tìm nạp ít tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực hơn có thể giúp giảm độ trễ này.

Bạn có thể kết hợp các lệnh tìm nạp tín hiệu đặt giá thầu đáng tin cậy khi trustedBiddingSignalsUrl được sử dụng lại giữa nhiều nhóm mối quan tâm. Khi có thể, hãy sử dụng cùng một trustedBiddingSignalsUrl cho tất cả các nhóm mối quan tâm.

Chỉ định các tiêu đề kiểm soát bộ nhớ đệm HTTP thích hợp để đảm bảo các lệnh tìm nạp tín hiệu đặt giá thầu đáng tin cậy được lưu vào bộ nhớ đệm trên các vị trí quảng cáo trên một trang web cụ thể. Tránh đặt trustedBiddingSignalsSlotSizeMode thành slot-size vì việc này sẽ ngăn việc lưu vào bộ nhớ đệm trên các vị trí quảng cáo khi kích thước của các vị trí đó khác nhau do URL được yêu cầu sẽ khác nhau.

Lượng tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực được tìm nạp nhỏ hơn

Độ trễ mạng có thể rất đáng kể và điều này chịu ảnh hưởng trực tiếp của lượng dữ liệu được chuyển trong quá trình tìm nạp tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực.

Ưu tiên lưu trữ dữ liệu cụ thể theo quảng cáo hoặc cụ thể theo nhóm mối quan tâm trong nhóm mối quan tâm, thay vì trên dịch vụ tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực. Chỉ dành dữ liệu tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực cho những tín hiệu thực sự theo thời gian thực, chẳng hạn như ngân sách chiến dịch hoặc nút tắt.

Mọi tín hiệu có thể cập nhật hằng ngày hoặc lâu hơn đều phải được lưu trữ trong nhóm mối quan tâm và cập nhật bằng thông tin cập nhật hằng ngày.

Không trả về tín hiệu đặt giá thầu đáng tin cậy cho các nhóm mối quan tâm bị lọc ra như mô tả trong phần "Lọc các nhóm mối quan tâm khỏi hoạt động đặt giá thầu trong dịch vụ Khoá/Giá trị".

Ưu tiên nhóm đối tượng có cùng mối quan tâm

Người bán sẽ sử dụng thời gian chờ để giới hạn cách sử dụng tài nguyên trình duyệt trên các trang của nhà xuất bản. Khi perBuyerCumulativeTimeouts được dùng để giới hạn thời gian người mua phải tìm nạp các tín hiệu đặt giá thầu đáng tin cậy và thực thi tập lệnh đặt giá thầu, người mua cần đảm bảo rằng họ ưu tiên các nhóm mối quan tâm để những nhóm có nhiều khả năng giành chiến thắng trong phiên đấu giá nhất sẽ thực thi trước. Ví dụ: nếu perBuyerCumulativeTimeouts được đặt thành 100 mili giây và quá trình tìm nạp tín hiệu đặt giá thầu đáng tin cậy của bên đặt giá thầu mất 50 mili giây, mỗi lệnh gọi generateBid() mất 10 mili giây và họ có 10 nhóm mối quan tâm trên một thiết bị, thì chỉ một nửa số nhóm mối quan tâm của họ mới có cơ hội tính toán giá thầu. Người mua trong ví dụ này nên ưu tiên các nhóm mối quan tâm theo thứ tự từ nhóm có nhiều khả năng chiến thắng nhất đến nhóm có ít khả năng chiến thắng nhất.

Nhóm mối quan tâm có thể chứa các mức độ ưu tiên tĩnh được xác định bằng trường priority. Nhóm mối quan tâm cũng có thể sử dụng các mức độ ưu tiên động có thể được tính toán trên dịch vụ tín hiệu đặt giá thầu đáng tin cậy và được trả về trình duyệt bằng phản hồi priorityVector cho lệnh tìm nạp tín hiệu đặt giá thầu đáng tin cậy.

Xin lưu ý rằng khi trình duyệt thực thi các nhóm mối quan tâm theo thứ tự ưu tiên từ cao nhất đến thấp nhất, việc này có thể xen kẽ các nhóm mối quan tâm từ nhiều nguồn gốc tham gia, điều này có thể làm mất hiệu quả tối ưu hoá group-by-origin.

Các phương pháp hay nhất dành cho người bán

Hãy đảm bảo bạn đang theo dõi và tối ưu hoá để tăng hiệu quả của phiên đấu giá Protected Audience API.

Tạo phiên đấu giá song song

Các kết nối mạng hiện đại và bộ xử lý đa nhân thực hiện rất tốt việc thực hiện đồng thời nhiều hoạt động. Trình duyệt có thể thực thi phiên đấu giá Protected Audience song song với các hoạt động khác. Cách tốt nhất để hỗ trợ việc này là gọi runAdAuction() càng sớm càng tốt. Nhận thấy rằng một số dữ liệu đầu vào cho runAdAuction() có thể không có sẵn từ sớm, ví dụ: những dữ liệu được gửi lại cho trình duyệt trong phản hồi theo ngữ cảnh, trình duyệt cho phép gọi runAdAution() trước khi có dữ liệu đầu vào và cung cấp các dữ liệu đầu vào này sau đó bằng cách sử dụng Lời hứa JavaScript. Để đạt được độ trễ phiên đấu giá thấp nhất có thể, bạn nên gọi runAdAuction() khi biết dữ liệu đầu vào interestGroupBuyers. Điều này cho phép nhiều phần của phiên đấu giá bắt đầu ngay lập tức, bao gồm cả việc tìm nạp các tín hiệu đặt giá thầu theo thời gian thực của bên đặt giá thầu.

Theo dõi phiên đấu giá

Thu thập chỉ số về phiên đấu giá. Trình duyệt có thể báo cáo các chỉ số độ trễ per-buyer cho người bán, cung cấp nhiều thông tin chi tiết về thời gian dành cho các phiên đấu giá của người bán. Người bán có thể sử dụng các chỉ số này để tìm cách tối ưu hoá phiên đấu giá, bao gồm cả thông tin về cách đặt thời gian chờ hiệu quả nhất. Người bán có thể chia sẻ các chỉ số về độ trễ của một người mua cụ thể với người mua đó để giúp họ tối ưu hoá hơn nữa.

Bên đặt giá thầu có thể có thông tin chi tiết về hiệu suất đặt giá thầu của các nhóm mối quan tâm của riêng họ, nhưng có thể không so sánh được hiệu suất này với các bên đặt giá thầu khác. Việc so sánh tỷ lệ chiến thắng tương đối và tỷ lệ từ chối giá thầu của các bên đặt giá thầu có thể giúp xác định các trường hợp lãng phí tài nguyên tính toán đặt giá thầu do các nhóm mối quan tâm không bao giờ tạo ra giá thầu khả thi hoặc đặt giá thầu quá mức với mẫu quảng cáo chưa được phê duyệt.

Bảo vệ khỏi các tập lệnh giá thầu chậm

Các tập lệnh đặt giá thầu mất nhiều thời gian có thể làm chậm phiên đấu giá Protected Audience API cho tất cả những người tham gia. Việc sử dụng thời gian chờ có thể ngăn các phiên đấu giá diễn ra chậm mà vẫn khôi phục doanh thu khi phiên đấu giá diễn ra chậm.

Người bán nên sử dụng perBuyerCumulativeTimeouts để ngăn chặn các phiên đấu giá diễn ra chậm, đồng thời vẫn chấp nhận giá thầu khi phiên đấu giá diễn ra chậm và hết thời gian chờ. Bạn nên sử dụng perBuyerCumulativeTimeouts thay vì sử dụng perBuyerTimeouts và perBuyerGroupLimits vì perBuyerCumulativeTimeouts không có ý kiến về số lượng nhóm mối quan tâm hoặc tốc độ của generateBid() (ví dụ: nhiều nhóm mối quan tâm đặt giá thầu nhanh và một số nhóm mối quan tâm đặt giá thầu chậm đều có thể hoàn tất trước khi hết thời gian chờ).

Bạn cũng nên sử dụng trường signal trong cấu hình phiên đấu giá để triển khai thời gian chờ tổng thể của phiên đấu giá nhằm ngăn chặn các phiên đấu giá quá dài trong trường hợp tín hiệu tính điểm đáng tin cậy tìm nạp và thực thi scoreAd() mất quá nhiều thời gian.

Tiếp theo là gì?

Chúng tôi muốn thảo luận với bạn để đảm bảo việc xây dựng một API phù hợp với tất cả mọi người.

Thảo luận về API

Giống như các API Hộp cát về quyền riêng tư khác, API này được ghi lại và thảo luận công khai.

Thử nghiệm với API

Bạn có thể thử nghiệm và tham gia cuộc trò chuyện về Protected Audience API.