Meningkatkan latensi lelang Protected Audience API

Semua orang berkepentingan untuk memastikan Protected Audience API beroperasi secara efisien:

• Pengguna yang menjelajahi web ingin situs dimuat dengan cepat. Artinya, developer harus mem-build dengan Protected Audience API secara efisien agar tidak menggunakan resource perangkat yang terbatas secara berlebihan, seperti resource komputasi atau jaringan, yang diperlukan untuk memuat situs dan iklan tersemat.
• Penayang ingin situs mereka dimuat dengan cepat, sehingga memberikan pengalaman yang efisien dan responsif kepada pengguna. Penayang juga menginginkan iklan yang efektif untuk memaksimalkan pendapatan mereka.
• Pengiklan dan teknologi iklan ingin iklan mereka ditampilkan dengan cepat untuk memberikan manfaat terbesar.

Dokumen ini menguraikan beberapa praktik terbaik untuk penerapan Protected Audience API, untuk memastikan situs Anda beroperasi dengan efisiensi maksimum.

Praktik terbaik pembeli (bidder)

Untuk memastikan Anda mengoptimalkan efisiensi lelang Protected Audience API, ikuti praktik terbaik berikut.

Lebih sedikit pemilik grup minat

Untuk melindungi bidder Protected Audience API dengan cara yang sama seperti browser melindungi origin yang berbeda di web menggunakan isolasi situs, browser menggunakan resource yang mahal (seperti proses sistem operasi) untuk melindungi setiap pemilik grup minat.

Untuk meminimalkan pengeluaran resource yang sangat mahal ini, memiliki sedikitnya pemilik grup minat sangatlah penting. Hindari memiliki grup minat yang berbeda yang dimiliki oleh berbagai subdomain. Misalnya, jika adtech.example memiliki grup minat yang dimiliki oleh cats.adtech.example dan dogs.adtech.example, browser kemungkinan akan menggunakan dua proses terpisah untuk menjalankan skrip bidding.

Bidding grup minat yang lebih sedikit

Browser harus melakukan penyiapan dan persiapan yang signifikan sebelum memanggil skrip generateBid() pembeli, seperti menyiapkan lingkungan eksekusi JavaScript bersih baru, serta mengurai dan memuat kode generateBid().

• Grup minat yang mewakili pengguna yang bukan target saat ini dari kampanye iklan aktif harus memiliki daftar materi iklan kosong. Hal ini mencegah Protected Audience API menjalankan generateBid() untuk grup minat tanpa iklan yang relevan.
• Menggabungkan grup minat yang serupa akan mengurangi frekuensi generateBid() harus dijalankan. Properti userBiddingSignals grup minat dapat digunakan untuk menyimpan metadata tambahan tentang pengguna, sehingga lebih sedikit grup minat tidak berarti penargetan yang kurang efektif.
• Protected Audience API mendukung batas yang ditentukan penjual pada jumlah grup minat, dan API bagi pembeli untuk menentukan prioritas relatif grup minat mereka. Batasan ini dapat digunakan untuk mengurangi jumlah skrip bidding yang akan dijalankan secara signifikan.

Memfilter grup minat dari bidding di layanan Nilai Kunci Anda

Jika pembeli dapat menentukan di server sinyal bidding tepercaya real-time bahwa grup minat tertentu tidak boleh mengajukan bid (misalnya, kampanye dinonaktifkan, dijeda, atau kehabisan anggaran, atau tidak boleh mengajukan bid pada penayang tertentu ini), mereka dapat menunjukkan hal ini ke browser dengan respons priorityVector untuk pengambilan sinyal bidding tepercaya. Jika hasil produk titik jarang dari priorityVector dan prioritySignals negatif, browser akan melewati pemanggilan generateBid() untuk grup minat ini. Anda dapat membaca mekanisme ini lebih lanjut di bagian"Memfilter dan Memprioritaskan Grup Minat" dalam penjelasan.

Menggunakan kembali lingkungan eksekusi JavaScript

Sebelum dapat mengeksekusi generateBid(), browser harus melakukan inisialisasi lingkungan eksekusi JavaScript baru. Proses ini dapat memerlukan waktu yang cukup lama, setara dengan jumlah waktu yang diperlukan generateBid() minimal untuk dieksekusi. Waktu ini dapat disimpan dengan menggunakan mode eksekusi grup menurut asal atau konteks beku.

Mode group-by-origin dapat menggunakan kembali lingkungan eksekusi jika grup minat digabungkan di origin yang sama, dan kemungkinan tidak akan memerlukan perubahan pada skrip bidding Anda; untuk mempelajari lebih lanjut, lihat deskripsi group-by-origin dalam penjelasan. Mode konteks beku dapat menggunakan kembali semua lingkungan eksekusi, tetapi mungkin memerlukan perubahan pada skrip bidding Anda. Untuk mempelajari lebih lanjut, lihat deskripsi frozen-context dalam penjelasan.

Menggunakan kembali skrip bidding

Gunakan skrip bidding yang sama untuk grup minat jika memungkinkan. Hal ini mencegah browser harus mendownload, mengurai, dan mengompilasi beberapa skrip (yang menimbulkan permintaan jaringan tambahan). Bidder masih dapat membedakan bidding berdasarkan informasi grup minat (misalnya, name atau userBiddingSignals) saat menggunakan skrip yang sama.

Tanpa header kontrol cache HTTP, skrip bidding tidak akan di-cache. Tentukan header yang sesuai untuk memastikan skrip tidak diambil secara tidak perlu. Jika ada beberapa lelang di halaman yang berjalan secara paralel, skrip bidding dari bidder yang sama akan digunakan kembali jika sudah ada di memori, dengan mengabaikan semantik penyimpanan dalam cache. Jika lelang berjalan secara berurutan, browser akan mematuhi mekanisme penyimpanan dalam cache HTTP.

Perhatikan bahwa browser memuat skrip bidding selama waktu bidding (untuk generateBid()) dan juga selama waktu pelaporan (untuk reportWin()). Jika header kontrol cache tidak ditetapkan, browser akan mengambil skrip yang sama dua kali, satu kali untuk setiap jangka waktu.

Oleh karena itu, sebaiknya tetapkan header kontrol cache di semua skrip Anda.

Menggunakan kembali trustedBiddingSignalsUrls

Latensi jaringan dan penggunaan resource dapat sangat signifikan. Pengambilan sinyal bidding tepercaya real-time yang lebih sedikit dapat membantu mengurangi latensi ini.

Pengambilan sinyal bidding tepercaya dapat digabungkan saat trustedBiddingSignalsUrl digunakan kembali di antara beberapa grup minat. Jika memungkinkan, gunakan trustedBiddingSignalsUrl yang sama untuk semua grup minat.

Tentukan header kontrol cache HTTP yang sesuai untuk memastikan pengambilan sinyal bidding tepercaya di-cache di seluruh slot iklan di halaman web tertentu. Hindari menetapkan trustedBiddingSignalsSlotSizeMode ke slot-size karena hal ini akan mencegah penyimpanan dalam cache di seluruh slot iklan jika ukuran slot berbeda karena URL yang diminta akan berbeda.

Pengambilan sinyal bidding tepercaya real-time yang lebih kecil

Latensi jaringan dapat sangat signifikan, dan hal ini secara langsung dipengaruhi oleh jumlah data yang ditransfer selama pengambilan sinyal bidding tepercaya real-time.

Sebaiknya simpan data khusus iklan atau khusus grup minat di grup minat, bukan di layanan sinyal bidding tepercaya real-time. Menyimpan data sinyal bidding tepercaya real-time hanya untuk sinyal yang benar-benar real-time, seperti anggaran kampanye atau kill-switch.

Setiap sinyal yang dapat diperbarui setiap hari atau lebih lama harus disimpan di grup minat dan diperbarui menggunakan pembaruan harian.

Jangan menampilkan sinyal bidding tepercaya untuk grup minat yang difilter seperti yang dijelaskan di bagian "Memfilter grup minat dari bidding di layanan Nilai Kunci/Nilai Anda".

Memprioritaskan grup minat

Penjual akan menggunakan waktu tunggu untuk membatasi penggunaan resource browser di halaman penayang. Jika perBuyerCumulativeTimeouts digunakan untuk membatasi waktu yang diperlukan pembeli untuk mengambil sinyal bidding tepercaya dan menjalankan skrip bidding, pembeli harus memastikan bahwa mereka memprioritaskan grup minat sehingga grup yang paling mungkin memenangkan lelang akan dijalankan terlebih dahulu. Misalnya, jika perBuyerCumulativeTimeouts ditetapkan ke 100 md dan pengambilan sinyal bidding tepercaya bidder memerlukan waktu 50 md, dan setiap pemanggilan generateBid() memerlukan waktu 10 md dan mereka memiliki 10 grup minat yang ada di perangkat, maka hanya setengah dari grup minat mereka yang akan memiliki peluang untuk menghitung bid. Pembeli dalam contoh ini harus memprioritaskan grup minat mereka secara berurutan dari yang paling mungkin menang hingga yang paling tidak mungkin menang.

Grup minat dapat berisi prioritas statis yang ditentukan dengan kolom priority-nya. Grup minat juga dapat menggunakan prioritas dinamis yang dapat dihitung di layanan sinyal bidding tepercaya mereka dan ditampilkan ke browser dengan respons priorityVector untuk pengambilan sinyal bidding tepercaya.

Perhatikan bahwa saat browser menjalankan grup minat dari prioritas tertinggi ke terendah, hal ini dapat menyelingi grup minat dari berbagai asal bergabung yang dapat mengalahkan pengoptimalan group-by-origin.

Praktik terbaik penjual

Pastikan Anda memantau dan mengoptimalkan efisiensi lelang Protected Audience API.

Memparalelkan lelang

Koneksi jaringan modern dan prosesor multi-core melakukan pekerjaan yang baik dalam melakukan beberapa aktivitas secara serentak. Browser dapat menjalankan lelang Protected Audience secara paralel dengan aktivitas lainnya. Hal ini dapat difasilitasi dengan memanggil runAdAuction() sedini mungkin. Dengan menyadari bahwa beberapa input ke runAdAuction() mungkin tidak tersedia sejak awal, misalnya, input yang dikirim kembali ke browser dalam respons kontekstual, browser memungkinkan pemanggilan runAdAution() sebelum tersedia, dan memberikan input ini di lain waktu menggunakan Promise JavaScript. Untuk mencapai latensi lelang serendah mungkin, runAdAuction() harus dipanggil saat input interestGroupBuyers diketahui. Hal ini memungkinkan banyak bagian lelang untuk segera dimulai, termasuk mengambil sinyal bidding real-time bidder.

Memantau lelang

Mengumpulkan metrik di lelang Anda. Browser dapat melaporkan metrik latensi per-buyer kepada penjual yang memberikan banyak insight tentang cara waktu dihabiskan dalam lelang penjual. Penjual dapat menggunakan metrik ini untuk mencari cara mengoptimalkan lelang mereka, termasuk mengetahui cara menetapkan waktu tunggu secara paling efektif. Penjual dapat membagikan metrik latensi pembeli tertentu kepada pembeli untuk membantu mereka mengoptimalkan lebih lanjut.

Bidder mungkin memiliki insight tentang performa bidding grup minat mereka sendiri, tetapi mereka mungkin tidak dapat membandingkannya dengan bidder lain. Membandingkan rasio menang relatif dan rasio penolakan bid untuk berbagai bidder dapat membantu mengidentifikasi kasus saat resource komputasi bidding terbuang karena grup minat tidak pernah menghasilkan bid yang layak atau bidding yang berlebihan dengan materi iklan yang tidak disetujui.

Melindungi dari skrip bid lambat

Skrip bidding yang memerlukan waktu berlebihan dapat memperlambat lelang Protected Audience API bagi semua pihak yang terlibat. Menggunakan waktu tunggu dapat mencegah lelang lambat sekaligus tetap memulihkan pendapatan saat lelang lambat.

Penjual harus menggunakan perBuyerCumulativeTimeouts untuk mencegah lelang lambat dan juga untuk tetap menerima bid saat lelang lambat dan mencapai waktu tunggu. Sebaiknya gunakan perBuyerCumulativeTimeouts daripada perBuyerTimeouts dan perBuyerGroupLimits karena perBuyerCumulativeTimeouts tidak memiliki pendapat tentang jumlah grup minat atau kecepatan generateBid() (misalnya, banyak grup minat yang mengajukan bid dengan cepat dan beberapa grup minat yang mengajukan bid dengan lambat dapat selesai sebelum waktu tunggu habis).

Menggunakan kolom signal konfigurasi lelang untuk menerapkan waktu tunggu lelang secara keseluruhan juga merupakan ide yang baik untuk mencegah lelang yang terlalu lama jika pengambilan sinyal penskoran tepercaya dan eksekusi scoreAd() memerlukan terlalu banyak waktu.

Penting: Catatan tentang waktu lelang - Orang sering bertanya "berapa lama waktu yang diperlukan untuk lelang Protected Audience?", "Berapa waktu tunggu yang harus ditetapkan penjual?" atau "Berapa latensi yang harus dioptimalkan pembeli?". Jawaban atas pertanyaan ini bergantung pada apa yang dioptimalkan oleh peserta hasil lelang. Penjual mungkin ingin memaksimalkan pendapatan iklan situs. Dalam hal ini, mereka harus bereksperimen dengan waktu tunggu yang berbeda untuk menemukan setelan yang memaksimalkan pendapatan. Memiliki waktu tunggu yang berbeda untuk desktop dan seluler mungkin berguna. Penggunaan Protected Audience dapat berubah dari waktu ke waktu seiring meningkatnya penggunaan, peserta lelang mengoptimalkan logika mereka, atau komputer berkembang, sehingga eksperimen yang berkelanjutan dapat bermanfaat. Jika pembeli mengoptimalkan untuk memenangkan sebagian besar lelang, mereka harus memantau dan mengoptimalkan latensi sinyal bidding tepercaya dan latensi generateBid(), serta mempertimbangkan untuk memprioritaskan grup minat mereka sehingga saat penjual menetapkan waktu tunggu yang ketat, mereka akan membuat bid terbaik terlebih dahulu.

Apa selanjutnya?

Kami ingin berbincang dengan Anda untuk memastikan bahwa kami membangun API yang berlaku untuk semua orang.

Diskusikan API

Seperti API Privacy Sandbox lainnya, API ini didokumentasikan dan dibahas secara publik.

Bereksperimen dengan API

Anda dapat bereksperimen dan berpartisipasi dalam percakapan tentang Protected Audience API.