Meningkatkan latensi lelang Protected Audience API

Demi kepentingan semua pihak, pastikan Protected Audience API beroperasi secara efisien:

  • Orang yang menjelajahi web ingin situs dimuat dengan cepat. Artinya, developer harus membangun dengan Protected Audience API secara efisien agar tidak menggunakan sumber daya perangkat terbatas secara berlebihan, seperti sumber daya komputasi atau jaringan, yang diperlukan untuk memuat situs dan iklan sematan.
  • 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 utilitas terbesar.

Dokumen ini menguraikan beberapa praktik terbaik untuk penerapan Protected Audience API, guna 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 berbagai origin 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 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 mereka.

Lebih sedikit grup minat yang mengajukan bid

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 bukan target kampanye iklan aktif saat ini 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 jumlah waktu 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. Batas ini dapat digunakan untuk mengurangi jumlah skrip bidding yang akan dijalankan secara signifikan.

Mengecualikan grup minat dari bidding di layanan Nilai/Kunci Anda

Jika pembeli dapat menentukan di server sinyal bidding tepercayanya secara 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 menunjukkannya ke browser dengan respons priorityVector terhadap pengambilan sinyal bidding tepercaya. Jika hasil produk titik jarang 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 menjalankan generateBid(), browser harus melakukan inisialisasi lingkungan eksekusi JavaScript baru. Proses ini dapat memakan waktu yang cukup lama, setara dengan waktu yang dibutuhkan generateBid() minimal untuk dieksekusi. Waktu ini dapat dihemat dengan menggunakan mode eksekusi group-by-origin atau frozen-context.

Mode group-by-origin dapat menggunakan kembali lingkungan eksekusi jika grup minat bergabung di origin yang sama, dan kemungkinan tidak memerlukan perubahan pada skrip bidding Anda; untuk mempelajari lebih lanjut, lihat deskripsi group-by-origin dalam penjelasan. Mode konteks yang dibekukan dapat menggunakan kembali semua lingkungan eksekusi yang memungkinkan, tetapi mungkin memerlukan perubahan pada skrip bidding Anda; untuk mempelajari lebih lanjut, lihat deskripsi frozen-context di 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 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 bidder yang sama akan digunakan kembali jika sudah ada di memori, dengan mengabaikan semantik penyiapan cache. Jika lelang berjalan secara berurutan, browser akan mematuhi mekanisme penyimpanan cache HTTP.

Perhatikan bahwa browser memuat skrip bidding selama waktu bid (untuk generateBid()) dan juga selama waktu pelaporan (untuk reportWin()). Jika header kontrol cache tidak ditetapkan, browser akan mengambil skrip yang sama dua kali, sekali 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. Lebih sedikit pengambilan sinyal bidding tepercaya real-time dapat membantu mengurangi latensi ini.

Pengambilan sinyal bidding tepercaya dapat digabungkan jika 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 pada halaman web tertentu. Hindari menyetel trustedBiddingSignalsSlotSizeMode ke slot-size karena hal ini akan mencegah penyimpanan dalam cache di seluruh slot iklan saat 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 dipengaruhi secara langsung oleh jumlah data yang ditransfer selama pengambilan sinyal bidding tepercaya real-time.

Lebih baik menyimpan data spesifik per iklan atau spesifik per grup minat di 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 anggaran kampanye atau tombol nonaktif.

Sinyal apa pun yang dapat diperbarui setiap hari atau lebih lama harus disimpan dalam grup minat dan diperbarui menggunakan update harian.

Jangan menampilkan sinyal bidding tepercaya untuk grup minat yang difilter seperti yang dijelaskan di bagian "Mengecualikan grup minat dari bidding di layanan Key/Value".

Memprioritaskan grup minat

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

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

Perhatikan bahwa saat browser mengeksekusi grup minat dari prioritas tertinggi hingga 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 dapat melakukan beberapa aktivitas secara bersamaan dengan baik. Browser dapat menjalankan lelang Protected Audience secara paralel dengan aktivitas lain. Hal ini dapat difasilitasi dengan sebaik-baiknya dengan memanggil runAdAuction() sedini mungkin. Menyadari bahwa beberapa input ke runAdAuction() mungkin tidak tersedia sejak awal, misalnya, input yang dikirim kembali ke browser dalam respons kontekstual, browser memungkinkan panggilan runAdAution() sebelum input tersebut tersedia, dan memberikan input ini di lain waktu menggunakan JavaScript Promises. Untuk mencapai latensi lelang serendah mungkin, runAdAuction() harus dipanggil saat input interestGroupBuyers diketahui. Hal ini memungkinkan banyak bagian lelang dimulai dengan segera, termasuk pengambilan sinyal bidding real-time bidder.

Memantau lelang Anda

Kumpulkan metrik di lelang Anda. Browser dapat melaporkan per-buyermetrik latensi kepada penjual yang memberikan banyak insight tentang penggunaan waktu dalam lelang penjual. Penjual dapat menggunakan metrik ini untuk mencari cara mengoptimalkan lelang mereka, termasuk menginformasikan cara menetapkan waktu tunggu secara paling efektif. Penjual dapat membagikan metrik latensi pembeli tertentu kepada pembeli untuk membantu mereka melakukan pengoptimalan 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 berbagai bidder dapat membantu mengidentifikasi kasus saat resource komputasi bidding terbuang karena grup minat tidak pernah menghasilkan bid yang layak atau bidding berlebihan dengan materi iklan yang tidak disetujui.

Melindungi dari skrip bid lambat

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

Penjual harus menggunakan perBuyerCumulativeTimeouts untuk mencegah lelang yang lambat dan juga untuk tetap menerima bid saat lelang lambat dan mencapai waktu tunggu. Penggunaan perBuyerCumulativeTimeouts lebih disarankan daripada penggunaan 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 menyelesaikan sebelum waktu tunggu).

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

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.