Jawaban atas pertanyaan umum (FAQ) terkait API relevansi dan pengukuran Privacy Sandbox.
Bagaimana Perbandingan Topik dengan Audiens Buatan Penjual (SDA)?
Topics dan SDA memberikan jenis informasi yang saling melengkapi, dan keduanya mengontrol penayang. Kami tidak percaya mereka bersaing satu sama lain. Sebaliknya, keduanya bekerja berdampingan atau dalam konteks yang berbeda untuk memaksimalkan peluang pembelian. Pembeli mempertimbangkan dan menggunakan banyak sinyal saat mengevaluasi tayangan secara terprogram, dan kami berharap Topics menjadi salah satu pertimbangan tersebut. Secara historis, penjual tidak menyertakan segmen audiens di lelang marketplace terbuka. Topics tempat yang mungkin digunakan akan digunakan. Sebagai gantinya, penjual telah menyediakan audiens untuk pembelian terprogram dalam transaksi yang dilakukan dengan pengiklan, agensi, atau DSP. Dalam kasus tersebut, penjual dan pembeli bertransaksi dengan sengaja di SDA. Jika Topics digunakan dalam kasus ini, topik dapat digunakan untuk satu atau beberapa hal berikut:
- Penjual melengkapi definisi audiensnya dengan Topics
- Pembeli menggunakan Topics sebagai sinyal tentang jumlah bid yang akan diajukan
- Pembeli yang menggunakan Topics untuk memvalidasi apakah SDA akurat
Apakah Protected Audience memberi Google kontrol atas pembuatan audiens?
Tidak. Situs dapat terus membangun audiensnya sendiri, baik di dalam maupun di luar Privacy Sandbox. Saat situs membuat audiens dalam Privacy Sandbox, pemilik situs atau proxy yang dipilih menentukan siapa yang dapat membuat audiens, apa saja audiens tersebut, bagaimana audiens tersebut diupdate, bagaimana audiens tersebut akan diajukan bid-nya, dan apakah akan menghapus pengguna dari audiens.
Apakah Protected Audience mendukung Grup Minat yang dibuat penayang?
Ya. Kami memahami bahwa penayang berhati-hati dalam memasukkan audiens mereka ke lelang berbasis OpenRTB saat ini karena khawatir terhadap kebocoran data. Penayang dapat membuat audiens sekarang di Protected Audience yang tidak memberikan tampilan lintas situs pengguna penayang individual tersebut kepada bidder. Kami senang dapat terus mengeksplorasi cara penayang memanfaatkan lingkungan kebocoran data Protected Audience yang berkurang.
Bagaimana aturan kualitas iklan diterapkan dalam lelang Protected Audience?
Ada sejumlah cara penerapan aturan kualitas iklan dalam lelang Protected
Audience. Setiap aspek ini
mirip dengan cara penegakan aturan kualitas iklan oleh SSP saat ini. Salah satu caranya adalah mengizinkan
lelang dengan materi iklan yang tidak dikenal memicu materi iklan agar masuk ke antrean untuk
dipindai. Kami telah menerima masukan bahwa SSP menginginkan dukungan yang lebih baik untuk
kasus penggunaan ini dan sedang merancang mekanisme yang dapat membuat feed renderUrls
yang dapat diaudit oleh SSP di luar band, lalu menyimpan informasinya di server
nilai kunci mereka. Cara lainnya adalah mewajibkan prapendaftaran iklan. Seperti
kasus sebelumnya, setelah materi iklan dipindai, hasilnya dapat dikaitkan ke
server nilai kunci. Kemudian, saat pembeli mengajukan bid dengan materi iklan tersebut (seperti yang ditunjukkan
oleh ID materi iklan yang kemungkinan mengikuti format yang sama dengan OpenRTB), logika
penskoran penjual dapat melakukan pencarian di server nilai kunci dan menentukan cara mendapatkan skor
dengan benar.
Apakah Protected Audience mendukung iklan video?
Ya. URL VAST dapat diteruskan ke dan keluar dari Protected Audience. Saat URL VAST dikeluarkan, teknologi sisi jual dapat mengoordinasikan cara mereka menggabungkan URL VAST pembeli sebelum dikirim ke pemutar. Menjelang persyaratan untuk beralih ke Frame Fenced (paling cepat 2026) dan lebih memperkuat perlindungan privasi pengguna, kami berharap ekosistem ini dapat terlibat dalam diskusi desain yang tentunya akan mencakup video.
Apakah Protected Audience mendukung iklan native?
Ya. URL JSON dapat diteruskan ke dan keluar dari Protected Audience. Saat URL JSON keluar, teknologi sisi jual dapat mengoordinasikan cara mereka menambahkan peristiwa yang diinginkan sebelum JSON final diteruskan ke kode rendering. Menjelang persyaratan untuk beralih ke Frame dengan Fence (paling cepat 2026) guna lebih memperkuat perlindungan privasi pengguna, kami memperkirakan ekosistem ini akan berinteraksi dalam diskusi desain yang kemungkinan akan menyertakan native.
Apakah rendering iklan Protected Audience menghambat inovasi?
Tidak. Rendering iklan selalu mengandalkan teknologi browser. Hal itu tidak berubah. Mungkin masalah ini khusus untuk rencana mewajibkan penggunaan Frame Fenced bersama dengan Protected Audience pada masa mendatang. Salah satu alasan mengapa rencana tersebut "di masa depan" adalah karena kami ingin teknologi Fenced Frames mendukung inovasi dan diferensiasi ekosistem dalam hal rendering iklan. Ada waktu bagi developer dan perusahaan yang tertarik untuk mempertimbangkan ke arah Fenced Frames yang mencakup cara mendukung pendekatan iklan native.
Apakah Protected Audience memungkinkan pendekatan kecepatan dan penilaian bid canggih yang ada saat ini di lelang tradisional?
Protected Audience menawarkan
opsi real-time bagi pembeli untuk memahami kecepatan dan anggaran kampanye. Dari
sudut pandang inventaris, penjual dapat memberikan sinyal lelang
kepada pembeli tentang konteks halaman dan hal lainnya. Jika penjual
memilih untuk mengirim permintaan bid kontekstual, pembeli juga dapat mempelajari
inventaris melalui mekanisme tersebut, lalu memberikan sinyal kontekstual (melalui perBuyerSignals) yang dapat digunakan dalam pembuatan bid
Protected Audience-nya. Pengguna awal sudah menghubungkan sistem machine learning ke
Protected Audience. Kami memahami bahwa perlu waktu untuk menyesuaikan sistem ini ke
bidding di lingkungan Protected Audience, tetapi penting untuk diperhatikan bahwa
penyesuaian dapat dilakukan dan sudah terjadi.
Apakah standar OpenRTB akan berfungsi di Protected Audience?
Ya. Pekerjaan ini sedang berlangsung di IAB Tech Lab melalui grup DSP dan SSP perwakilan yang diawasi dengan baik. Tampaknya jalur ke depan adalah menggunakan bagian protokol OpenRTB sebagai standar komunikasi di dalam lelang Protected Audience, dan kami mengetahui bahwa pengguna awal sudah membuatnya seperti itu.
Apakah Protected Audience mengharuskan perusahaan untuk mempertahankan dua arsitektur terpisah untuk penayangan iklan?
Tidak. Protected Audience tidak memerlukan pemeliharaan dua arsitektur terpisah. Pilihan arsitektur Anda adalah milik Anda sendiri. Seiring dengan berkembangnya iklan online dari tahun ke tahun, begitu juga kompleksitas sistem yang mendukungnya. Menjadikan internet lebih pribadi bagi pengguna akan menyebabkan lebih banyak kerumitan dan membutuhkan upaya. Perusahaan teknologi iklan dapat memilih untuk mempertahankan dua arsitektur terpisah atau mem-build Protected Audience ke dalam arsitektur gabungan dengan lelang tradisional.
Apa yang akan terjadi pada lelang tradisional setelah lebih banyak perusahaan teknologi iklan mendukung Protected Audience?
Kami memperkirakan lelang kontekstual akan tetap relevan karena berbagai alasan, termasuk transaksi, kampanye yang menargetkan audiens non-pihak pertama, dan banyak skenario kontekstual lainnya. Metrik ini juga tetap berharga jika tidak ada Grup Minat atau bid di Protected Audience gagal mencapai nilai minimum atau mematuhi aturan kualitas iklan.
Apakah lelang Protected Audience bertentangan dengan upaya Pengoptimalan Jalur Pasokan (SPO) ekosistem untuk mengurangi total jumlah perantara antara pengiklan dan penayang dan/atau duplikasi peluang iklan tertentu?
Tidak. Iklan pemenang di Protected Audience akan meneruskan maksimum dua entitas penjual (misalnya, Platform Sisi Suplai (SSP) dan server iklan penayang) dan sesedikit mungkin tidak ada—jika pembeli membangun integrasi langsung dengan penayang.
Duplikasi permintaan yang sama menggunakan beberapa perantara tetap menjadi pilihan penayang. Protected Audience tidak akan memengaruhi satu cara atau cara lainnya.
Lelang Protected Audience terjadi di luar sistem real-time server ke server saat ini agar tidak membocorkan data pengguna lintas situs. Sebagian orang mungkin mengatakan bahwa tindakan ini meniru permintaan iklan. Perlu beberapa kompromi untuk mendapatkan privasi yang dapat dibuktikan secara teknis. Namun, dalam jangka panjang mungkin saja ekosistem memutuskan untuk menggunakan Protected Audience tanpa lelang sisi server tradisional. Pilihan ini dapat menghasilkan jalur pasokan yang lebih optimal.
Apakah Protected Audience mengurangi nilai infrastruktur pembentukan traffic yang ada?
Seperti yang kita pahami, hal yang berubah dalam kaitannya dengan kueri per detik adalah banyak SSP menggunakan ID lintas situs sebagai fitur untuk menentukan apakah akan mengirim permintaan ke DSP atau tidak. Penurunan ID lintas situs sehingga memengaruhi teknik pembentukan traffic yang ada. Hal ini akan tetap berlaku baik penayang ingin menjalankan lelang Protected Audience atau tidak.
Kami telah mempelajari pembentukan traffic dengan banyak SSP dan menemukan solusi, termasuk caching dan pemfilteran berbasis kontekstual. Seiring waktu, kami berharap developer dapat memanfaatkan Agregasi Pribadi untuk membantu lebih lanjut memahami preferensi bidding DSP dan memfilter yang sesuai.
Pada akhirnya, beberapa infrastruktur lama yang dibuat berdasarkan ID lintas situs tidak akan lagi berguna.
Apakah permintaan baru yang dihasilkan dari lelang Protected Audience akan membatasi kapasitas SSP?
Kami telah mendengar dari beberapa SSP bahwa kapasitas bukanlah masalah atau bagian penting proposisi nilai SSP dari sudut pandang integrasi. Bagi SSP yang khawatir tentang panggilan baru dalam proses lelang, kami menyadari bahwa perusahaan sudah membantu SSP dalam hal kapasitas dan ingin memperluas layanan tersebut untuk mendukung Protected Audience. Beri tahu kami jika Anda ingin kami menghubungkan Anda dengan salah satu perusahaan tersebut.
Bagaimana prioritas ditangani di Protected Audience saat ada resource yang bersaing di browser?
Protected Audience umumnya telah mengikuti paradigma standar dalam membuat kontrol yang memungkinkan penjual menentukan jumlah waktu dan resource yang dapat digunakan bidder, serta membuat alat yang memungkinkan pembeli memutuskan cara terbaik dalam menggunakan resource yang tersedia bagi mereka. Kontrol dan alat ini tersedia saat ini, tetapi manfaat penuhnya akan direalisasikan setelah adopsi oleh pembeli dan penjual. Selain itu, Chrome terus mengerjakan berbagai peningkatan infrastruktur pada kecepatan lelang (misalnya, crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/119).
Bagaimana cara Protected Audience mengatasi masalah latensi?
Sebelumnya, sebelum Protected
Audience, bidding real-time yang
terjadi di server memiliki penjual yang menentukan waktu tunggu yang ketat pada respons pembeli
untuk menjaga latensi. Kami menambahkan berbagai kontrol waktu tunggu
yang ditentukan penjual yang sangat mirip (lihat
dokumentasi untuk
perBuyerCumulativeTimeouts, perBuyerTimeouts, sellerTimeout) ke Protected
Audience untuk mencapai sasaran yang sama, yaitu menjaga latensi agar tetap diperiksa. Kontrol
ini juga mendorong peserta lelang untuk mengoptimalkan logika mereka guna memastikan
resource digunakan secara paling efisien untuk mendukung ekosistem teknologi iklan dan
pengalaman pengguna berkualitas tinggi.
Chrome juga terus mengerjakan berbagai peningkatan infrastruktur pada kecepatan lelang (misalnya crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323). Kami mengundang masukan terkait kedua bagian dari upaya latensi ini: alat tambahan yang akan berguna bagi pembeli dan penjual, serta laporan tentang bottleneck yang diamati yang harus diselidiki oleh engineer Chrome.
Apakah mem-build untuk Protected Audience di perangkat merupakan upaya yang sia-sia saat ada Layanan Bidding dan Lelang (B&A)?
Tidak. Di perangkat cukup untuk kasus penggunaan teknologi iklan. Layanan Bidding dan Lelang adalah solusi skala horizontal opsional saat teknologi iklan ingin berinvestasi lebih banyak dalam resource komputasi bid daripada yang diizinkan browser. Pengembangan di perangkat merupakan investasi yang bagus, karena sebagian besar pekerjaan akan dapat digunakan kembali meskipun developer nantinya memutuskan untuk berpartisipasi dalam lingkungan layanan Bidding dan Lelang. Sebagian besar pipe dan infrastruktur yang dibangun akan terus berfungsi dengan cara serupa.
Apakah Trusted Execution Environment (TEE) berbasis cloud akan memenuhi persyaratan Protected Audience untuk mendorong bisnis menggunakan Google Cloud?
Privacy Sandbox telah merancang API untuk memberikan privasi dan keamanan yang kuat, dan kami belum mengambil keputusan desain apa pun untuk memberi manfaat bagi Google Cloud. Dukungan kami untuk penyedia cloud dimulai dengan AWS karena kami memahami jumlah penyedia teknologi iklan yang memilih Amazon. Selain AWS dan Google Cloud, kami berharap dapat mendukung penyedia cloud lainnya di masa mendatang, dan kami menerima saran dari penyedia cloud lainnya. Jika latensi menjadi kekhawatiran, cloud menawarkan pilihan lokasi kepada pelanggan yang mempersingkat jarak ke penyedia cloud lainnya.
Apakah Privacy Sandbox akan mengizinkan Trusted Execution Environment (TEE) untuk berjalan di pusat data cloud non-publik?
Trusted Execution Environments (TEE) yang dapat diaudit adalah bagian dari model privasi dan keamanan kami. Kami memulai dengan TEE yang ditawarkan oleh penyedia cloud publik karena langkah keamanan yang ketat. Untuk lebih jelasnya, satu-satunya API yang memerlukan penggunaan Lingkungan Eksekusi Tepercaya dalam waktu dekat adalah Attribution Reporting API dan Private Aggregation API, dan tidak melibatkan pemanggilan TEE secara real time dalam setelan lelang. Kami akan terus mengeksplorasi dukungan untuk berbagai opsi di luar solusi berbasis cloud publik.
Bukankah akan lebih mahal untuk menjalankan Lingkungan Eksekusi Tepercaya di cloud publik dibandingkan di pusat data teknologi iklan lokal?
Model privasi TEE kami saat ini mendapatkan manfaat dari praktik keamanan implementasi cloud publik, dan kami mempertanyakan asumsi apa pun bahwa mengoperasikan Trusted Execution Environment secara lokal akan lebih murah. Berikut adalah beberapa pertimbangan biaya untuk praktik tersebut:
Penyedia cloud publik harus menerapkan standar keamanan yang sangat tinggi. Misalnya, AWS adalah penyedia cloud terkemuka dengan praktik keamanan yang mapan. Secara khusus, AWS Nitro memiliki model keamanan yang didokumentasikan untuk memastikan bahwa Nitro Enklave mencegah operator mengakses data yang diproses di enklave, dan resource yang dilindungi (seperti kunci dekripsi) hanya tersedia untuk kode resmi yang berjalan di Enklave. Ada juga akses fisik untuk dipertimbangkan. AWS telah merancang dan menerapkan mitigasi untuk risiko akses fisik, termasuk dari karyawan Amazon. TEE berbasis hardware yang ada mungkin tidak bertahan dari semua serangan fisik, yang dirancang untuk dilakukan cloud publik. Selain itu, Amazon baru-baru ini melibatkan NCC Group, sebuah perusahaan riset independen, untuk meninjau desain Nitro mereka, yang berfokus pada klaim keamanan terkait akses oleh karyawan internal. Laporan publik menunjukkan bahwa desain AWS memenuhi klaim mereka.
Praktik ini memerlukan biaya untuk diterapkan, didukung, dan ditingkatkan seiring waktu. Dengan cloud publik yang terdistribusi secara global dan tersedia secara luas, biaya tersebut tersebar di basis pelanggan yang luas.
Apakah Privacy Sandbox mengubah penagihan?
Tidak. Perusahaan teknologi iklan dan pemanggil API lainnya dapat terus melihat apakah sesuatu dirender di halaman beserta harganya.
Apakah pembatasan frekuensi dapat dilakukan di Privacy Sandbox?
Protected Audience mendukung
pembatasan frekuensi lintas situs dalam Grup Minat yang sama melalui
objek prevWinsMs. Fungsi generateBid() pembeli dalam lelang Protected
Audience dapat membuat logika yang dapat menginformasikan strategi bidding berdasarkan
hasil eksposur iklan sebelumnya untuk browser yang sama.
Ada beberapa solusi yang dapat digunakan untuk pembatasan frekuensi di luar Protected Audience, tetapi tidak sepenuhnya dipetakan ke teknik lintas situs yang dimiliki teknologi iklan dengan cookie pihak ketiga.
- Cookie pihak pertama: teknologi iklan dapat menggunakan data pihak pertama mereka sendiri untuk pembatasan frekuensi di situs mereka sendiri
- CHIP: teknologi iklan dapat mengelola batas frekuensi di tingkat per situs menggunakan cookie terpartisi
- Penyimpanan Bersama
SelectURL(): setelah teknologi iklan memenangkan lelang dan sebelum merender materi iklan, teknologi iklan dapat memanggil Penyimpanan Bersama untuk mengakses data lintas situs dan memilih materi iklan yang tepat berdasarkan frekuensi melalui gate output Pilih URL.
Solusi pembatasan frekuensi non-Protected Audience yang fokus pada privasi yang memberikan utilitas teknologi iklan yang signifikan bukanlah hal yang mudah karena alasan berikut:
- Saat ini belum jelas berdasarkan masukan teknologi iklan apakah sinyal frekuensi dapat menoleransi derau.
- Kami telah menerima masukan teknologi iklan yang konsisten bahwa sinyal frekuensi lintas situs harus tersedia selama waktu lelang, yang memerlukan sinyal lintas situs yang tidak memiliki derau agar tersedia untuk digunakan dalam lelang iklan apa pun. Tindakan ini dapat mengungkapkan banyak informasi tentang aktivitas pengguna di seluruh situs, sehingga merusak sasaran privasi Privacy Sandbox.
- Kami sensitif terhadap latensi dan solusi di perangkat yang mungkin memberikan sinyal ini dapat menyebabkan latensi dan mengganggu lingkungan lelang
- Solusi mungkin memerlukan API baru, yang harus melalui proses proposal W3C.
Dengan demikian, membangun solusi batas frekuensi di luar Protected Audience tidak dalam rencana langsung kami, tetapi kami terbuka untuk masukan seputar cara potensial untuk menyelesaikan kasus penggunaan ini.
Bagaimana dengan kasus penggunaan yang tidak tercakup oleh Privacy Sandbox?
API Privacy Sandbox memberikan elemen penyusun utama untuk iklan yang menjaga privasi, tempat developer memiliki fleksibilitas untuk menentukan cara disatukan. Pendekatan elemen penyusun memungkinkan bisnis untuk berinovasi dan mengembangkan solusi yang memberikan nilai bagi pelanggan mereka. Privacy Sandbox tidak dimaksudkan untuk menjadi solusi menyeluruh untuk semua kasus penggunaan. Kami percaya itu akan menjadi hasil yang buruk. Sebaliknya, developer dan bisnis akan terus mewujudkan ide mereka melalui berbagai teknologi, termasuk Privacy Sandbox API yang mereka integrasikan ke dalam solusi mereka.