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. PropertiuserBiddingSignals
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.
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.