Meningkatkan latensi lelang Protected Audience API

Semua pihak harus memastikan bahwa Protected Audience API beroperasi secara efisien:

• Orang yang menjelajahi web ingin situs dimuat dengan cepat. Artinya, developer harus membuat aplikasi dengan Protected Audience API secara efisien agar tidak menggunakan secara berlebihan resource perangkat yang terbatas, seperti resource komputasi atau jaringan, yang diperlukan untuk memuat situs dan iklan sematannya.
• Penayang ingin situs mereka dimuat dengan cepat, yang 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 utilitas 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 jumlah pemilik grup minat yang paling sedikit sangatlah penting. Hindari memiliki grup minat berbeda yang dimiliki oleh berbagai subdomain. Misalnya, jika adtech.example memiliki grup minat yang dimiliki oleh cats.adtech.example dan dogs.adtech.example, browser mungkin akan menggunakan dua proses terpisah untuk menjalankan skrip bidding-nya.

Lebih sedikit bidding grup minat

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

• Grup minat yang mewakili pengguna yang saat ini bukan target kampanye iklan aktif harus memiliki daftar materi iklan yang 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 untuk jumlah grup minat, dan API untuk pembeli guna menentukan prioritas relatif grup minat mereka. Batas ini dapat digunakan untuk mengurangi jumlah skrip bidding yang dijalankan secara signifikan.

Memfilter grup minat dari bidding di layanan Kunci/Nilai

Jika pembeli dapat menentukan dalam 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 khusus ini), mereka dapat menunjukkan hal ini ke browser dengan respons priorityVector ke pengambilan sinyal bidding tepercaya. Jika produk titik sparse yang dihasilkan 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 penjelasannya.

Menggunakan kembali lingkungan eksekusi JavaScript

Sebelum browser dapat menjalankan generateBid(), browser harus melakukan inisialisasi lingkungan eksekusi JavaScript baru. Proses ini dapat memerlukan banyak waktu, setara dengan jumlah waktu yang dapat diperlukan generateBid() minimal untuk dijalankan. Waktu ini dapat disimpan dengan menggunakan mode eksekusi kelompok demi asal atau konteks frozen.

Mode group-by-origin dapat menggunakan kembali lingkungan eksekusi jika grup minat bergabung di asal yang sama, dan kemungkinan tidak memerlukan perubahan pada skrip bidding Anda; untuk mempelajari lebih lanjut, lihat deskripsi group-by-origin dalam penjelasan. Mode konteks beku dapat menggunakan kembali kemungkinan 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 mendownload, mengurai, dan mengompilasi beberapa skrip (yang menimbulkan permintaan jaringan tambahan). Bidder tetap dapat membedakan bidding berdasarkan informasi grup minat (misalnya, name atau userBiddingSignals) saat menggunakan skrip yang sama.

Gunakan kembali trustedBiddingSignalsUrls

Latensi jaringan dan penggunaan resource bisa menjadi sangat signifikan. Lebih sedikit pengambilan sinyal bidding tepercaya real-time 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 disimpan dalam cache di seluruh slot iklan di halaman tertentu. Jangan tetapkan trustedBiddingSignalsSlotSizeMode ke slot-size karena hal ini akan mencegah penyimpanan 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 bisa menjadi sangat signifikan, dan hal ini langsung dipengaruhi oleh banyaknya data yang ditransfer selama pengambilan sinyal bidding tepercaya real-time.

Lebih suka menyimpan data khusus iklan atau khusus grup minat dalam grup minat, daripada di layanan sinyal bidding tepercaya real-time. Cadangkan data sinyal bidding tepercaya real-time hanya untuk sinyal yang benar-benar real-time, seperti penganggaran kampanye atau tombol kill.

Sinyal apa pun yang dapat diperbarui setiap hari atau lebih lama harus disimpan di grup minat dan diperbarui menggunakan info terbaru harian.

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

Memprioritaskan grup minat

Penjual akan menggunakan waktu tunggu untuk membatasi penggunaan resource browser di halaman penayang. Saat perBuyerCumulativeTimeouts digunakan untuk membatasi berapa lama pembeli harus mengambil sinyal bidding tepercaya dan menjalankan skrip bidding mereka, penting bagi pembeli untuk memastikan mereka memprioritaskan grup minatnya sehingga mereka yang kemungkinan besar akan memenangkan lelang akan dieksekusi terlebih dahulu. Misalnya, jika perBuyerCumulativeTimeouts ditetapkan ke 100 milidetik dan pengambilan sinyal bidding tepercaya bidder memerlukan waktu 50 milidetik, dan setiap pemanggilan generateBid() memerlukan waktu 10 milidetik serta memiliki 10 grup minat yang ada di perangkat, hanya setengah dari grup minat mereka yang akan memiliki peluang untuk menghitung bid. Dalam contoh ini, pembeli harus memprioritaskan grup minat mereka secara berurutan dari yang paling mungkin menang hingga yang paling kecil kemungkinannya untuk menang.

Grup minat dapat berisi prioritas statis yang ditentukan dengan kolom priority. Grup minat juga dapat menggunakan prioritas dinamis yang dapat dihitung berdasarkan layanan sinyal bidding tepercaya dan ditampilkan ke browser dengan respons priorityVector pada pengambilan sinyal bidding tepercaya.

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

Praktik terbaik penjual

Pastikan Anda memantau dan mengoptimalkan efisiensi lelang Protected Audience API.

Paralelkan lelang

Koneksi jaringan modern dan prosesor multi-core mampu melakukan beberapa aktivitas secara bersamaan. Browser dapat menjalankan lelang Protected Audience secara paralel dengan aktivitas lainnya. Hal ini dapat difasilitasi sebaik mungkin dengan memanggil runAdAuction() sedini mungkin. Setelah menyadari bahwa beberapa input untuk runAdAuction() mungkin tidak tersedia sejak awal, misalnya, input yang dikirim kembali ke browser dalam respons kontekstual, browser mengizinkan 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. Dengan begitu, banyak bagian lelang dapat dimulai dengan segera, 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 penggunaan waktu dalam lelang penjual. Penjual dapat menggunakan metrik ini untuk mencari cara mengoptimalkan lelang, termasuk menginformasikan cara menetapkan waktu tunggu secara paling efektif. Penjual dapat membagikan metrik latensi pembeli tertentu dengan 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 kemenangan relatif dan rasio penolakan bid untuk bidder yang berbeda dapat membantu mengidentifikasi kasus ketika resource komputasi bidding terbuang karena grup minat tidak pernah menghasilkan bid yang valid atau bidding berlebihan dengan materi iklan yang tidak disetujui.

Lindungi dari skrip bid yang lambat

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

Penjual sebaiknya menggunakan perBuyerCumulativeTimeouts untuk mencegah lelang yang lambat dan juga tetap menerima bid saat lelang lambat dan mencapai waktu tunggu. Menggunakan perBuyerCumulativeTimeouts lebih disarankan untuk menggunakan perBuyerTimeouts dan perBuyerGroupLimits karena perBuyerCumulativeTimeouts tidak memiliki opini terkait jumlah grup minat atau kecepatan generateBid() (mis., banyak grup minat yang mengajukan bid dengan cepat dan beberapa grup minat yang mengajukan bid dengan lambat dapat diselesaikan 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 dibutuhkan lelang Protected Audience?", "untuk apa penjual menetapkan waktu tunggu?" atau "latensi apa yang harus dioptimalkan pembeli?". Jawaban atas pertanyaan ini bergantung pada hasil lelang yang dioptimalkan oleh peserta. Penjual mungkin ingin memaksimalkan pendapatan iklan situs, sehingga mereka harus bereksperimen dengan waktu tunggu yang berbeda-beda untuk menemukan setelan yang memaksimalkan pendapatan. Memiliki waktu tunggu yang berbeda untuk desktop dan seluler dapat berguna. Penggunaan Protected Audience dapat berubah dari waktu ke waktu seiring peningkatan adopsi, peserta lelang mengoptimalkan logika mereka, atau perkembangan komputer, sehingga eksperimen yang berkelanjutan dapat memberikan manfaat. 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 harus menghasilkan 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.