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

Đảm bảo Protected Audience API hoạt động hiệu quả là điều có lợi nhất cho mọi người:

  • 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ả sao cho không sử dụng quá nhiều tài nguyên hạn chế của thiết bị (chẳng hạn như tài nguyên điện toán hoặc tài nguyên mạng) cần thiết để tải trang web và quảng cáo nhúng trên trang web.
  • Nhà xuất bản muốn trang web của họ tải nhanh, mang lại 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.
  • Các nhà quảng cáo và công nghệ quảng cáo đều muốn quảng cáo của họ hiển thị nhanh để cung cấp tiện ích tuyệt vời 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 với hiệu quả tối đa.

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

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

Ít chủ sở hữu nhóm mối quan tâm hơn

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

Để giảm thiểu chi tiêu cho các tài nguyên rất tốn kém này, bạn phải có ít chủ sở hữu nhóm mối quan tâm nhất. Tránh sở hữu nhiều nhóm mối quan tâm thuộc 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 2 quy trình riêng biệt để chạy tập lệnh đặt giá thầu.

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

Trình duyệt phải thiết lập và chuẩn bị đáng kể 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 sạch mới, đồng thời phân tích cú pháp và tải mã generateBid().

  • Nhóm mối quan tâm đại diện cho người dùng không phải là mục tiêu hiện tại của 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 mối quan tâm mà không có quảng cáo phù hợp.
  • 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 chạy generateBid(). Bạn có thể 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. Nhờ đó, việc giảm số nhóm mối quan tâm không đồng nghĩa với việc nhắm mục tiêu kém hiệu quả.
  • Protected Audience API hỗ trợ các giới hạn do người bán chỉ định về số lượng nhóm 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 có cùng mối quan tâm. Các giới hạn này có thể được dùng để giảm đáng kể số lượng tập lệnh đặt giá thầu cần chạy.

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

Nếu người mua 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ị vô hiệu hoá, bị tạm dừng hoặc nằm ngoài ngân sách hoặc không được đặt giá thầu cho nhà xuất bản cụ thể này), thì họ có thể cho trình duyệt biết điều này bằng phản hồi priorityVector cho việc tìm nạp tín hiệu đặt giá thầu đáng tin cậy. Nếu tích số điểm thưa thớt thu được của priorityVector và prioritySignals là số â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 nhóm mối quan tâm" của phần giải thích.

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

Trước khi trình duyệt 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 tối thiểu mà chính generateBid() 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 theo nhóm theo nguồn gốc hoặc chế độ thực thi theo ngữ cảnh cố định.

Chế độ group-by-origin có thể sử dụng lại các môi trường thực thi trong trường hợp các nhóm mối quan tâm được tham gia 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ả về group-by-origin trong phần giải thích. Chế độ ngữ cảnh cố định có thể sử dụng lại tất cả các môi trường thực thi, nhưng có thể yêu cầu bạn phải thay đổi tập lệnh đặt giá thầu. Để tìm hiểu thêm, hãy xem nội dung mô tả về 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 (làm phát sinh thêm 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.

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ể. Giảm độ trễ này nếu tìm nạp tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực ít hơn.

Các phương thức tìm nạp tín hiệu đặt giá thầu đáng tin cậy có thể được kết hợp khi trustedBiddingSignalsUrl được sử dụng lại cho 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ượt tìm nạp tín hiệu đặt giá thầu đáng tin cậy được lưu vào bộ nhớ đệm trong các vùng quảng cáo trên một trang web cụ thể. Tránh đặt trustedBiddingSignalsSlotSizeMode thành slot-size vì điều này sẽ ngăn việc lưu vào bộ nhớ đệm trên các vùng quảng cáo khi kích thước của các vùng quảng cáo khác nhau do URL được yêu cầu sẽ khác nhau.

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

Độ trễ của mạng có thể rất đáng kể và điều này bị ảnh hưởng trực tiếp bởi lượng dữ liệu được chuyển trong các lần 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 theo quảng cáo cụ thể hoặc 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ỉ đặt trước 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ư lập ngân sách chiến dịch hoặc tắt nút chuyển.

Mọi tín hiệu có thể được 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 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 mục "Lọ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 các nhóm mối quan tâm

Người bán sẽ sử dụng thời gian chờ để giới hạn cách các tài nguyên trình duyệt được sử dụng trên các trang của nhà xuất bản. Khi bạn dùng perBuyerCumulativeTimeouts để giới hạn khoảng 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, thì điều quan trọng là người mua phải đả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 thắng phiên đấu giá sẽ thực thi trước tiên. 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, thì mỗi lệnh gọi generateBid() mất 10 mili giây và 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ọ có cơ hội tính 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 của mình theo thứ tự từ ít khả năng thắng lợi nhất đến ít có khả năng thắng.

Nhóm mối quan tâm có thể chứa mức độ ưu tiên không đổi được xác định bằng trường priority. Nhóm mối quan tâm cũng có thể sử dụng 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 của họ và được trả về trình duyệt với phản hồi priorityVector cho lần 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 từ mức ưu tiên cao nhất đến thấp nhất, điều này có thể xen kẽ các nhóm mối quan tâm từ nhiều nguồn gốc tham gia khác nhau. Điều này có thể đánh bại hoạt động 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 tính hiệu quả của phiên đấu giá Protected Audience API.

Song song hoá các phiên đấu giá

Kết nối mạng hiện đại và bộ xử lý đa nhân làm việc rất hiệu quả khi 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. Việc này có thể được hỗ trợ tốt nhất bằng cách 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 ngay từ đầu, chẳng hạn như các 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 chúng có sẵn 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ễ thấp nhất có thể trong phiên đấu giá, runAdAuction() sẽ được gọi khi xác định được đầ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 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ề các phiên đấu giá của bạn. Trình duyệt có thể báo cáo 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 những chỉ số này để tìm cách tối ưu hoá phiên đấu giá của họ, bao gồm cả việc thông báo cách đặt thời gian chờ hiệu quả nhất. Người bán có thể chia sẻ chỉ số độ 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 nhóm mối quan tâm của riêng họ, nhưng có thể không so sánh được thông tin này với những bên đặt giá thầu khác. Việc so sánh tỷ lệ thắng thầu và tỷ lệ từ chối giá thầu tương đối của các bên đặt giá thầu khác nhau có thể giúp xác định các trường hợp tài nguyên điện toán đặt giá thầu bị lãng phí do các nhóm mối quan tâm không bao giờ tạo ra giá thầu khả thi hoặc quá trình đặt giá thầu quá mức với mẫu quảng cáo không được phê duyệt.

Ngăn chặn các tập lệnh giá thầu chậm

Các tập lệnh đặt giá thầu mất quá nhiều thời gian có thể làm chậm phiên đấu giá Protected Audience API đối với mọi người có liên quan. Việc sử dụng thời gian chờ có thể ngăn phiên đấu giá chậm trong khi 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 phiên đấu giá chậm cũng như để vẫn chấp nhận giá thầu khi phiên đấu giá chậm và hết thời gian chờ. Bạn nên sử dụng perBuyerCumulativeTimeouts để sử dụng perBuyerTimeouts và perBuyerGroupLimits vì perBuyerCumulativeTimeouts không quan tâm đến 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à ít nhóm mối quan tâm đặt giá thầu chậm có thể hoàn tất trước khi hết thời gian chờ).

Việc 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á cũng là một ý tưởng nên để ngăn các phiên đấu giá quá dài trong trường hợp việc tìm nạp tín hiệu tính điểm đáng tin cậy và việc 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.