Mọi người đều mong muốn Protected Audience API hoạt động hiệu quả:
- Những người duyệt web muốn các 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á nhiều tài nguyên thiết bị có hạn (chẳng hạn như tài nguyên điện toán hoặc mạng) cần thiết để tải các trang web và quảng cáo được nhúng của chú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à có khả năng phản hồi. 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 muốn quảng cáo của họ hiển thị nhanh chóng để mang lại tiện ích tối đa.
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 cho người mua (bên đặt giá thầu)
Để đảm bảo bạn đang tối ưu hoá 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.
Ít chủ sở hữu nhóm đối tượng có cùng mối quan tâm hơn
Để bảo vệ những người đặ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 cơ chế cô lập trang web, trình duyệt sẽ sử dụng các tài nguyên tốn kém (chẳng hạn như các quy trình của hệ điều hành) để bảo vệ từng chủ sở hữu nhóm đối tượng có cùng 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, việc có ít chủ sở hữu nhóm lợi ích nhất là điều rất quan trọng. Tránh việc có nhiều nhóm lợi ích 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 hai quy trình riêng biệt để chạy các tập lệnh đặt giá thầu.
Ít nhóm đối tượng có cùng mối quan tâm đặt giá thầu
Trình duyệt phải thực hiện quá trình 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ột môi trường thực thi JavaScript mới hoàn toàn, đồng thời phân tích cú pháp và tải mã generateBid().
- Các nhóm sở thích đạ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 sẽ 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 mà không có quảng cáo liên quan. - Việc kết hợp các nhóm sở thích tương tự sẽ giảm số lần phải chạy
generateBid(). Bạn có thể dùng thuộc tínhuserBiddingSignalscủa một 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, ít nhóm mối quan tâm hơn không nhất thiết có nghĩa là nhắm mục tiêu 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 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 mối quan tâm. Bạn có thể sử dụng những giới hạn này để giảm đáng kể số lượng tập lệnh đặt giá thầu cần chạy.
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ị
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 lợi ích không nên đặt giá thầu (ví dụ: chiến dịch bị vô hiệu hoá, 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 cho lệnh 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 của priorityVector và prioritySignals là số âm, thì trình duyệt sẽ bỏ qua việc gọi generateBid() cho nhóm lợi ích 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 đối tượng có cùng mối quan tâm" của tài liệu 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à một 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 theo nhóm theo nguồn hoặc 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 lợi ích được kết hợp trên cùng một nguồn gốc và có thể không yêu cầu thay đổi đối với tập lệnh đặt giá thầu của bạn; để tìm hiểu thêm, hãy xem phần mô tả group-by-origin trong tài liệu giải thích. Chế độ ngữ cảnh cố định có thể sử dụng lại hầu hết mọi môi trường thực thi nhưng có thể yêu cầu bạn thay đổi tập lệnh đặt giá thầu; để tìm hiểu thêm, hãy xem phần mô tả frozen-context trong thông báo giải thích.
Sử dụng lại tập lệnh đặt giá thầu
Nếu có thể, hãy sử dụng cùng một tập lệnh đặt giá thầu cho các nhóm dựa trên mối quan tâm. Đ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 các yêu cầu mạng bổ sung). Bên đặt giá thầu vẫn có thể phân biệt hoạt động đặt giá thầu dựa trên thông tin về 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 tiêu đề thích hợp để đảm bảo tập lệnh không được tìm nạp một cách không cần thiết. Nếu có nhiều phiên đấu giá chạy song song trên trang, thì tập lệnh đặt giá thầu của cùng một bên đặt giá thầu sẽ được 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ả trong thời gian báo cáo (đối với reportWin()). Nếu tiêu đề kiểm soát bộ nhớ đệm không được đặt, 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 của mì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 giảm số lượt tìm nạp tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực có thể giúp giảm độ trễ này.
Bạn có thể kết hợp các lần tìm nạp tín hiệu đặt giá thầu đáng tin cậy khi trustedBiddingSignalsUrl được 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 tiêu đề kiểm soát bộ nhớ đệm HTTP phù 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 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ì điều này sẽ ngăn chặ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ấy các tín hiệu đặt giá thầu đáng tin cậy theo thời gian thực với kích thước 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 bởi 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.
Nên lưu trữ dữ liệu dành riêng cho quảng cáo hoặc dữ liệu dành riêng cho nhóm lợi ích trong nhóm lợi ích, 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 riêng 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 công tắc ngắt.
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ập nhật bằng các bản cập nhật hằng ngày.
Đừ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 như mô tả trong "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 mà 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 các tập lệnh đặt giá thầu, thì người mua cần đảm bảo rằng họ ưu tiên các nhóm lợi ích để những nhóm có nhiều khả năng giành chiến thắng trong phiên đấu giá 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 một bên đặt giá thầu mất 50 mili giây, đồng thời mỗi lệnh gọi generateBid() mất 10 mili giây và có 10 nhóm lợi ích trên một thiết bị, thì chỉ một nửa số nhóm lợi ích của họ sẽ 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 lợi ích theo thứ tự từ có khả năng thắng cao nhất đến có khả năng thắng thấp nhất.
Các nhóm đối tượng có cùng 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. Các nhóm mối quan tâm cũng có thể sử dụng các mức độ ưu tiên linh hoạt 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ề cho trình duyệt bằng phản hồi priorityVector cho hoạt động 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ừ các nguồn tham gia khác nhau, điều này có thể làm giảm khả năng tối ưu hoá group-by-origin.
Các phương pháp hay nhất dành cho người bán
Đảm bảo rằng bạn đang giám sát và tối ưu hoá hiệu quả của phiên đấu giá Protected Audience API.
Tải song song các phiên đấu giá
Các kết nối mạng hiện đại và bộ xử lý đa nhân hoạt động 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 một phiên đấu giá sử dụng Protected Audience API song song với các hoạt động khác. Bạn nên gọi runAdAuction() càng sớm càng tốt để có thể thực hiện việc này một cách hiệu quả nhấ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ư 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ó sẵn và cung cấp những dữ liệu đầu vào này vào thời điểm muộn hơn bằng cách sử dụng JavaScript Promises. Để đạt được độ trễ đấu giá thấp nhất có thể, bạn nên gọi runAdAuction() khi biết đầ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 người đặt giá thầu.
Theo dõi phiên đấu giá
Thu thập các chỉ số về phiên đấu giá. Trình duyệt có thể báo cáo per-buyercác chỉ số về độ trễ cho những người bán cung cấp nhiều thông tin chi tiết về thời gian diễn ra 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ả việc cung cấp thông tin về 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á thêm.
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 lợi ích của riêng họ, nhưng họ có thể không so sánh được thông tin này với các bên đặt giá thầu khác. Việc so sánh tỷ lệ thắng tương đối và tỷ lệ từ chối giá thầu của các bên đặt giá thầu khác nhau có thể giúp xác định những trường hợp mà tài nguyên tính toán giá thầu bị lãng phí do các nhóm lợi ích không bao giờ tạo ra giá thầu khả thi hoặc đặt giá thầu quá mức bằng những mẫu quảng cáo chưa được phê duyệt.
Ngăn chặn các tập lệnh đặt giá thầu chậm
Những 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 tất cả những người tham gia. Việc sử dụng thời gian chờ có thể ngăn chặn các phiên đấu giá diễn ra chậm trong khi vẫn thu hồi đượ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 và vẫn chấp nhận giá thầu khi phiên đấu giá diễn ra chậm và đạt đến thời gian chờ. Bạn nên sử dụng perBuyerCumulativeTimeouts thay vì 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ụ: cả 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 đề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 cấu hình đấu giá để triển khai thời gian chờ đấu giá tổng thể nhằm ngăn chặn các phiên đấu giá diễn ra quá lâu trong trường hợp việc tìm nạp và thực thi tín hiệu tính điểm đáng tin cậy 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.