Sinyal Aplikasi yang Dilindungi untuk mendukung iklan instal aplikasi yang relevan

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Proposal ini tunduk pada proses pendaftaran dan pengesahan Privacy Sandbox. Untuk informasi lebih lanjut terkait pengesahan, lihat link pengesahan yang diberikan. Update mendatang pada proposal ini akan menjelaskan persyaratan untuk mendapatkan akses ke sistem ini.

Iklan instal aplikasi seluler, juga dikenal sebagai iklan akuisisi pengguna, adalah jenis iklan seluler yang didesain untuk mendorong pengguna mendownload aplikasi seluler. Iklan ini biasanya ditayangkan kepada pengguna berdasarkan minat dan demografi mereka, dan sering kali muncul di dalam aplikasi seluler lain seperti game, media sosial, dan aplikasi berita. Saat pengguna mengklik iklan instal aplikasi, mereka akan diarahkan langsung ke app store untuk mendownload aplikasi tersebut.

Misalnya, pengiklan yang mencoba mendorong penginstalan baru untuk aplikasi pesan antar makanan seluler baru di Amerika Serikat dapat menargetkan iklannya kepada pengguna yang berlokasi di AS, juga bagi mereka yang sebelumnya pernah berinteraksi dengan aplikasi pesan antar makanan lain.

Hal ini biasanya diterapkan dengan menyertakan sinyal kontekstual, pihak pertama, dan pihak ketiga antara teknologi iklan untuk membuat profil pengguna berdasarkan ID Iklan. Model machine learning teknologi iklan menggunakan informasi ini sebagai input untuk memilih iklan yang relevan bagi pengguna, dan memiliki kemungkinan tertinggi untuk menghasilkan sebuah konversi.

API berikut ini diusulkan untuk mendukung iklan instal aplikasi efektif yang meningkatkan privasi pengguna, dengan menghilangkan pengandalan pada ID pengguna lintas pihak:

1. Protected App Signals API: Berfokus pada penyimpanan dan pembuatan fitur rekayasa teknologi iklan, yang mewakili potensi minat pengguna. Teknologi iklan menyimpan sinyal peristiwa per aplikasi yang ditentukan sendiri, seperti penginstalan aplikasi, pembukaan pertama, tindakan pengguna (leveling dalam game, pencapaian), aktivitas pembelian, atau waktu di aplikasi. Sinyal ditulis dan disimpan di perangkat untuk mencegah kebocoran data, dan hanya tersedia untuk logika teknologi iklan yang menyimpan sinyal tertentu selama Protected Auction berjalan di lingkungan yang aman.
2. Ad Selection API: API ini menyediakan API untuk mengonfigurasi dan menjalankan Protected Auction yang berjalan di Trusted Execution Environment (TEE) tempat teknologi iklan mengambil kandidat iklan, menjalankan inferensi, menghitung bid, dan melakukan penskoran untuk memilih iklan "pemenang" menggunakan Protected App Signals dan informasi kontekstual real-time yang disediakan penayang.

Berikut adalah ringkasan garis besar cara kerja Protected App Signals untuk mendukung iklan instal aplikasi yang relevan. Bagian berikut di dalam dokumen ini memberikan detail lebih lanjut tentang masing-masing langkah.

• Seleksi sinyal: Saat pengguna menggunakan aplikasi seluler, teknologi iklan menyeleksi sinyal dengan menyimpan peristiwa aplikasi yang ditentukan teknologi iklan untuk menayangkan iklan yang relevan menggunakan Protected App Signals API. Peristiwa ini disimpan dalam penyimpanan di perangkat yang dilindungi, mirip dengan Audiens Kustom, dan dienkripsi sebelum dikirim dari perangkat sehingga hanya layanan Bidding dan Lelang yang berjalan dalam Trusted Execution Environment dengan kontrol keamanan dan privasi yang sesuai yang dapat mendekripsinya untuk bidding dan penskoran iklan.
• Encoding Sinyal: Sinyal disiapkan sesuai ritme yang terjadwal oleh logika teknologi iklan kustom. Tugas latar belakang Android mengeksekusi logika ini untuk melakukan encoding di perangkat guna menghasilkan payload Protected App Signals yang nantinya dapat digunakan secara real time untuk pemilihan iklan selama Protected Auction. Payload tersebut disimpan dengan aman di perangkat hingga dikirim untuk lelang.
• Pemilihan Iklan: Untuk memilih iklan yang relevan bagi pengguna, SDK penjual mengirim payload terenkripsi dari Protected App Signals dan mengonfigurasi Protected Auction. Dalam lelang, logika kustom pembeli menyiapkan Protected App Signals bersama dengan data kontekstual yang diberikan penayang (data yang biasanya dibagikan dalam permintaan iklan RTB Terbuka) untuk merekayasa fitur yang ditujukan untuk pemilihan iklan (pengambilan iklan, inferensi, dan pembuatan bid). Serupa dengan Protected Audience, pembeli mengirimkan iklan ke penjual untuk penskoran akhir dalam Protected Auction.
  • Pengambilan Iklan: Pembeli menggunakan Protected App Signals dan data kontekstual yang diberikan penayang untuk merekayasa fitur yang relevan dengan minat pengguna. Fitur ini digunakan untuk mencocokkan iklan yang memenuhi kriteria penargetan. Iklan yang tidak sesuai dengan anggaran akan dikecualikan. Iklan top k kemudian dipilih untuk bidding.
  • Bidding: Logika bidding kustom milik pembeli menyiapkan data kontekstual yang disediakan penayang dan Protected App Signals, untuk merekayasa fitur yang digunakan sebagai input untuk machine learning pembeli bagi inferensi dan bidding pada iklan kandidat, dalam batas yang menjaga privasi yang tepercaya. Pembeli kemudian akan mengembalikan iklan pilihannya kepada penjual.
  • Penskoran Penjual: Logika penskoran kustom milik penjual memberi skor iklan yang dikirim oleh Pembeli yang berpartisipasi, dan memilih iklan pemenang untuk dikirim kembali ke aplikasi untuk dirender.
• Pelaporan: Peserta lelang menerima laporan kemenangan dan laporan kekalahan yang berlaku. Kami sedang mempelajari mekanisme yang menjaga privasi guna menyertakan data untuk pelatihan model dalam laporan kemenangan.

Linimasa

Menyeleksi Protected App Signals

Sinyal adalah representasi dari berbagai macam interaksi pengguna dalam aplikasi yang telah ditentukan oleh teknologi iklan, agar berguna untuk menayangkan iklan yang relevan. Aplikasi atau SDK terintegrasi dapat menyimpan atau menghapus Protected App Signals yang ditentukan oleh teknologi iklan berdasarkan aktivitas pengguna, seperti pembukaan aplikasi, pencapaian, aktivitas pembelian, atau waktu di aplikasi. Protected App Signals disimpan dengan aman di perangkat, dan dienkripsi sebelum dikirim dari perangkat sehingga hanya layanan Bidding dan Lelang yang berjalan dalam Trusted Execution Environment dengan kontrol keamanan dan privasi yang sesuai yang dapat mendekripsinya untuk bidding dan penskoran iklan. Serupa dengan Custom Audience API, sinyal yang disimpan di perangkat tidak dapat dibaca atau diperiksa oleh aplikasi atau SDK; tidak ada API untuk membaca nilai sinyal, dan API dirancang untuk menghindari kebocoran keberadaan sinyal. Logika kustom teknologi iklan telah melindungi akses ke sinyal yang telah diseleksi untuk merekayasa fitur yang berfungsi sebagai dasar untuk pemilihan iklan di dalam Protected Auction.

Protected App Signals API

Protected App Signals API mendukung pengelolaan sinyal menggunakan mekanisme delegasi yang mirip dengan yang digunakan untuk audiens kustom. Protected App Signals API memungkinkan penyimpanan sinyal dalam bentuk nilai skalar tunggal, atau sebagai deret waktu. Sinyal deret waktu dapat digunakan untuk menyimpan hal-hal seperti durasi sesi pengguna. Sinyal deret waktu menawarkan utilitas untuk menerapkan durasi tertentu menggunakan aturan pengecualian pertama masuk, pertama keluar. Jenis data sinyal skalar, atau setiap elemen sinyal deret waktu, adalah array byte. Setiap nilai diperkaya dengan nama paket aplikasi yang menyimpan sinyal, dan stempel waktu pembuatan panggilan API sinyal toko. Informasi tambahan ini tersedia di JavaScript encoding sinyal. Contoh ini menunjukkan struktur sinyal yang dimiliki oleh teknologi iklan tertentu:

Contoh ini menunjukkan sinyal skalar dan sinyal deret waktu yang terkait dengan adtech1.com:

• Sinyal skalar dengan kunci nilai base64 "A1c" dan nilai "c12Z". Penyimpanan sinyal telah dipicu oleh com.google.android.game_app pada 1 Juni 2023.
• Daftar sinyal dengan kunci "dDE" yang telah dibuat oleh dua aplikasi berbeda.

Teknologi iklan dialokasikan sejumlah ruang tertentu untuk menyimpan sinyal di perangkat. Sinyal akan memiliki TTL maksimum, yang akan ditentukan.

Protected App Signals akan dihapus dari penyimpanan jika aplikasi yang membuatnya di-uninstal, diblokir agar tidak menggunakan Protected App Signals API, atau jika data aplikasinya dihapus oleh pengguna.

Protected App Signals API terdiri dari bagian-bagian berikut ini:

• Java dan JavaScript API untuk menambahkan, memperbarui, atau menghapus sinyal.
• JavaScript API untuk memproses sinyal yang dipertahankan guna menyiapkannya untuk rekayasa fitur lebih lanjut secara real time selama Protected Auction yang berjalan di Trusted Execution Environment (TEE).

Menambahkan, memperbarui, atau menghapus sinyal

Teknologi iklan dapat menambahkan, memperbarui, atau menghapus sinyal dengan fetchSignalUpdates() API. API ini mendukung delegasi yang serupa dengan delegasi audiens kustom Protected Audience.

Untuk menambahkan sinyal, teknologi iklan milik pembeli yang tidak memiliki kehadiran SDK di aplikasi harus berkolaborasi dengan teknologi iklan yang memiliki kehadiran di perangkat, seperti partner pengukuran seluler (MMP) dan platform sisi suplai (SSP). Protected App Signals API bertujuan untuk mendukung teknologi iklan ini dengan menyediakan solusi yang fleksibel untuk pengelolaan Protected App Signals, dengan memungkinkan pemanggil di perangkat untuk memanggil pembuatan Protected App Signals atas nama pembeli. Proses ini disebut sebagai delegasi, dan memanfaatkan fetchSignalUpdates() API. fetchSignalUpdates() mengambil URI dan mengambil daftar pembaruan sinyal. Sebagai ilustrasi, fetchSignalUpdates() mengeluarkan permintaan GET ke URI yang telah diberikan untuk mengambil daftar pembaruan yang akan diterapkan ke penyimpanan sinyal lokal. Endpoint URL, yang dimiliki oleh pembeli, akan merespons kembali dengan daftar perintah JSON.

Perintah JSON yang didukung adalah:

• put: menyisipkan atau mengganti nilai skalar untuk kunci yang diberikan.
• put_if_not_present: menyisipkan nilai skalar untuk kunci yang diberikan, jika belum ada nilai yang disimpan. Opsi ini dapat berguna, misalnya untuk menetapkan ID eksperimen bagi pengguna tertentu, dan menghindari penggantian jika sudah ditetapkan oleh aplikasi lain.
• add: menambahkan elemen ke deret waktu yang terkait dengan kunci yang diberikan. Parameter maxSignals menentukan jumlah sinyal maksimum dalam deret waktu. Jika ukurannya terlampaui, elemen sebelumnya akan dihapus. Jika berisi nilai skalar, kunci akan otomatis diubah menjadi deret waktu.
• remove: menghapus konten yang terkait dengan kunci yang diberikan.

{
   "put": {
    "A1c": "c12Z",
    "dDE": "d23d",
  },
  "put_if_not_present": {
    "aA9": "a1zfC3"
  }
  "append": {
    "bB1": {"values": ["gh12D", "d45g"], "maxSignals": 20}
  },
  "remove": ["c0D"]
}

Semua kunci dan nilai dinyatakan dalam Base64.

Perintah yang tercantum di atas dimaksudkan untuk memberikan penyisipan, penimpaan, dan penghapusan semantik untuk sinyal skalar, serta penyisipan, penambahan, dan penimpaan rangkaian lengkap untuk sinyal deret waktu. Menghapus dan menimpa semantik pada elemen tertentu dari sinyal deret waktu harus dikelola selama berlangsungnya proses encoding dan pemadatan; misalnya selama encoding yang mengabaikan nilai dalam deret waktu yang digantikan, atau dikoreksi oleh yang lebih baru dan menghapusnya selama proses pemadatan berlangsung.

Sinyal yang tersimpan akan secara otomatis dikaitkan dengan aplikasi yang melakukan permintaan pengambilan, dan penjawab permintaan ("situs" atau "asal" teknologi iklan terdaftar), ditambah waktu pembuatan permintaan. Semua sinyal akan disimpan atas nama teknologi iklan yang terdaftar di Privacy Sandbox, URI "situs"/"asal" harus cocok dengan data teknologi iklan yang terdaftar. Jika teknologi iklan yang meminta tidak terdaftar, permintaan akan ditolak.

Kuota dan penghapusan penyimpanan

Setiap teknologi iklan memiliki jumlah ruang terbatas di perangkat pengguna untuk menyimpan sinyal. Kuota ini ditentukan per teknologi iklan, sehingga sinyal yang dipilih dari berbagai aplikasi akan berbagi kuota. Jika kuota terlampaui, sistem akan mengosongkan ruang penyimpanan dengan menghapus nilai sinyal sebelumnya berdasarkan yang pertama kali masuk, dan pertama kali keluar. Agar penghapusan tidak sering dijalankan terlalu sering, sistem akan menerapkan logika pengelompokan untuk memungkinkan cerukan kuota dalam jumlah terbatas, dan mengosongkan ruang tambahan setelah logika penghapusan dipicu.

Encoding di perangkat untuk transmisi data

Guna menyiapkan sinyal untuk pemilihan iklan, logika kustom per pembeli memiliki akses yang dilindungi ke sinyal dan peristiwa per aplikasi yang disimpan. Tugas latar belakang sistem Android berjalan setiap jamnya untuk menjalankan logika encoding kustom per pembeli yang telah didownload ke perangkat. Logika encoding kustom per pembeli mengenkode sinyal per aplikasi, lalu mengompresi sinyal per aplikasi ke dalam payload yang sesuai dengan kuota per pembeli tersebut. Payload kemudian dienkripsi dalam batas penyimpanan perangkat yang dilindungi, lalu dikirimkan ke layanan Bidding dan Lelang.

Teknologi iklan menentukan tingkat pemrosesan sinyal yang ditangani oleh logika kustomnya sendiri. Misalnya, Anda dapat menginstrumentasikan solusi Anda untuk menghapus sinyal sebelumnya, dan menggabungkan sinyal diperkuat atau yang serupa dari berbagai aplikasi ke dalam sinyal baru yang menggunakan lebih sedikit ruang.

Jika pembeli belum mendaftarkan encoder sinyal, berarti sinyalnya tidak disiapkan, dan tidak ada sinyal hasil seleksi di perangkat yang dikirim ke layanan Bidding dan Lelang.

Detail selengkapnya tentang kuota penyimpanan, payload, dan permintaan akan tersedia dalam update mendatang. Selain itu, kami akan memberikan informasi lebih lanjut tentang cara untuk menyediakan fungsi kustom.

Alur kerja pemilihan iklan

Dengan proposal ini, kode kustom teknologi iklan hanya dapat mengakses Protected App Signals dalam Protected Auction (Ad Selection API) yang berjalan di dalam TEE. Untuk mendukung kebutuhan kasus penggunaan instal aplikasi lebih lanjut, iklan kandidat diambil selama berlangsungnya Protected Auction secara real time. Hal ini berbeda dengan kasus penggunaan pemasaran ulang saat iklan kandidat telah diketahui sebelum lelang terjadi.

Proposal ini menggunakan alur kerja pemilihan iklan yang serupa dengan proposal Protected Audience, dengan update untuk mendukung kasus penggunaan penginstalan aplikasi. Untuk mendukung persyaratan komputasi bagi rekayasa fitur dan pemilihan iklan real time, lelang untuk iklan instal aplikasi harus berjalan di layanan Bidding dan Lelang yang berjalan di dalam TEE. Akses ke Protected App Signals selama berlangsungnya Protected Auction tidak didukung dengan lelang di perangkat.

Alur kerja pemilihan iklan adalah sebagai berikut:

1. SDK penjual mengirimkan payload terenkripsi di perangkat dari Protected App Signals.
2. Server penjual membuat konfigurasi lelang dan mengirimkannya ke layanan Bidding dan Lelang Tepercaya penjual, bersama dengan payload terenkripsi, untuk memulai alur kerja pemilihan iklan.
3. Layanan Bidding dan Lelang penjual meneruskan payload ke server frontend pembeli tepercaya yang turut berpartisipasi.
4. Layanan bidding pembeli menjalankan logika pemilihan iklan sisi beli
   1. Eksekusi logika pengambilan iklan sisi beli.
   2. Eksekusi logika bidding sisi beli.
5. Logika penskoran sisi jual dijalankan.
6. Iklan dirender, dan pelaporannya dimulai.

Memulai alur kerja pemilihan iklan

Saat aplikasi siap untuk menampilkan iklan, SDK teknologi iklan (biasanya SSP) akan memulai alur kerja pemilihan iklan dengan mengirimkan data kontekstual yang relevan dari penayang, dan payload terenkripsi per pembeli untuk disertakan di dalam permintaan agar dikirim ke Protected Auction menggunakan panggilan getAdSelectionData. Ini adalah API yang sama yang digunakan untuk alur kerja pemasaran ulang dan dijelaskan dalam proposal Integrasi Bidding dan Lelang untuk Android.

Untuk memulai pemilihan iklan, penjual meneruskan daftar pembeli yang berpartisipasi dan payload terenkripsi dari Protected App Signals di perangkat. Dengan informasi ini, server iklan sisi jual menyiapkan SelectAdRequest untuk layanan SellerFrontEnd tepercaya mereka.

Penjual menetapkan hal berikut ini:

• Payload yang diterima dari getAdSelectionData, yang berisi Protected App Signals.

• Sinyal kontekstual menggunakan:

  • auction_config.auction_signals (untuk informasi tentang lelang)

  • auction_config.seller_signals (untuk sinyal penjual

  • auction_config.per_buyer_config["buyer"].buyer_signals (untuk sinyal pembeli)

• Daftar pembeli yang disertakan di dalam lelang menggunakan kolom buyer_list.

Eksekusi logika pemilihan iklan sisi beli

Pada tingkat yang tinggi, logika kustom pembeli menggunakan data kontekstual yang diberikan oleh penayang dan Protected App Signals untuk memilih dan menerapkan bid ke iklan yang relevan untuk permintaan iklan tersebut. Platform ini memungkinkan pembeli untuk mempersempit kumpulan besar iklan yang tersedia ke iklan yang paling relevan (top k), yang bid-nya dihitung sebelum iklan tersebut dikembalikan ke penjual untuk pemilihan akhir.

Sebelum melakukan bidding, pembeli memulai dengan kumpulan iklan yang besar. Ini terlalu lambat untuk penghitungan bid setiap iklan sehingga pembeli harus memilih kandidat top k dari kumpulan yang besar terlebih dahulu. Selanjutnya, pembeli perlu menghitung bid untuk setiap kandidat top k tersebut. Kemudian, iklan dan bid tersebut ditampilkan kepada penjual untuk pemilihan akhir.

1. Layanan BuyerFrontEnd menerima permintaan iklan.
2. Layanan BuyerFrontEnd mengirimkan permintaan ke layanan bidding pembeli. Layanan bidding pembeli menjalankan UDF yang disebut prepareDataForAdRetrieval(), yang membuat permintaan untuk mendapatkan kandidat top k dari Layanan Pengambilan Iklan. Layanan bidding mengirimkan permintaan ini ke endpoint server pengambilan yang telah dikonfigurasi.
3. Layanan Pengambilan Iklan menjalankan getCandidateAds() UDF, yang memfilter hingga ke kumpulan iklan kandidat top k, yang dikirim ke layanan bidding pembeli.
4. Layanan bidding pembeli menjalankan generateBid() UDF, yang memilih kandidat terbaik, menghitung bid-nya, lalu menampilkannya ke layanan BuyerFrontEnd.
5. Layanan BuyerFrontEnd menampilkan iklan dan bid kepada penjual.

Ada beberapa detail penting tentang alur ini – terutama terkait bagaimana setiap bagian berkomunikasi satu sama lain, dan bagaimana platform tersebut menyediakan fitur seperti kemampuan untuk membuat prediksi machine learning guna mengambil iklan top k dan menghitung bid-nya.

Sebelum kami melihat bagian-bagian ini secara lebih detail, ada beberapa catatan arsitektur penting tentang TEE pada diagram di atas.

Layanan bidding pembeli berisi layanan inferensi secara internal. Teknologi iklan dapat mengupload model machine learning ke layanan bidding pembeli. Kami akan menyediakan API JavaScript untuk teknologi iklan, guna membuat prediksi atau membuat penyematan dari model ini dari dalam UDF yang berjalan di layanan bidding pembeli. Tidak seperti Layanan Pengambilan Iklan, layanan bidding pembeli tidak memiliki layanan nilai kunci untuk menyimpan metadata iklan apa pun.

Layanan Pengambilan Iklan mencakup layanan nilai kunci secara internal. Teknologi iklan dapat mewujudkan key-value pair ke dalam layanan ini dari servernya sendiri, di luar dari batasan privasi. Kami akan menyediakan JavaScript API untuk teknologi iklan agar dapat dibaca dari layanan nilai kunci ini, dari dalam UDF yang berjalan di dalam Layanan Pengambilan Iklan. Tidak seperti layanan bidding pembeli, Layanan Pengambilan Iklan tidak berisi layanan inferensi.

Satu pertanyaan utama yang dijawab oleh desain ini adalah cara untuk membuat prediksi waktu pengambilan dan waktu bidding. Jawaban untuk keduanya dapat melibatkan solusi yang disebut faktorisasi model.

Faktorisasi model

Faktorisasi model adalah teknik yang memungkinkan untuk memecah satu model menjadi beberapa bagian, lalu menggabungkan bagian-bagian tersebut menjadi sebuah prediksi. Dalam kasus penggunaan Instal Aplikasi, model sering menggunakan tiga jenis data: data pengguna, data kontekstual, dan data iklan.

Dalam kasus non faktorisasi, satu model dilatih pada ketiga jenis data tersebut. Dalam kasus terfaktorkan, kami bagi modelnya menjadi beberapa bagian. Hanya bagian yang berisi data pengguna yang bersifat sensitif. Artinya, hanya model dengan bagian pengguna yang perlu dijalankan di dalam batas kepercayaan, di layanan inferensi layanan bidding pembeli.

Hal ini memungkinkan desain berikut:

1. Pisahkan model menjadi bagian pribadi (data pengguna), dan satu atau beberapa bagian non pribadi (data kontekstual dan iklan).
2. Secara opsional, teruskan beberapa atau semua bagian non pribadi sebagai argumen ke UDF yang perlu untuk membuat prediksi. Misalnya, penyematan kontekstual diteruskan ke UDF dalam per_buyer_signals.
3. Secara opsional, teknologi iklan dapat membuat model untuk bagian non pribadi, lalu mewujudkan penyematan dari model tersebut ke penyimpanan nilai kunci Layanan Pengambilan Iklan. UDF pada Layanan Pengambilan Iklan dapat mengambil penyematan ini saat runtime.
4. Untuk membuat prediksi selama UDF, gabungkan penyematan pribadi dari layanan inferensi dengan penyematan non pribadi dari argumen fungsi UDF, atau penyimpanan nilai kunci dengan operasi seperti produk titik. Ini adalah prediksi akhirnya.

Setelah dijelaskan, kami dapat melihat setiap UDF secara lebih mendetail. Kami akan menjelaskan apa yang mereka lakukan, bagaimana mereka berintegrasi, dan bagaimana mereka dapat membuat prediksi yang diperlukan untuk memilih iklan top k dan menghitung bid-nya.

UDF prepareDataForAdRetrieval()

prepareDataForAdRetrieval() yang berjalan di layanan bidding pembeli bertanggung jawab untuk membuat payload permintaan yang akan dikirim ke layanan pengambilan iklan untuk mengambil iklan kandidat top k.

prepareDataForAdRetrieval() mengambil informasi berikut ini:

• Payload per pembeli yang diterima dari getAdSelectionData. Payload ini berisi Protected App Signals.
• auction_signals dari sinyal kontekstual (untuk info tentang lelang) dan buyer_signals (untuk kolom sinyal pembeli).

prepareDataForAdRetrieval() melakukan dua hal:

• Fiturisasi: jika inferensi waktu pengambilan diperlukan, inferensi akan mengubah sinyal masuk menjadi fitur yang akan digunakan selama panggilan ke layanan inferensi untuk mendapatkan penyematan pribadi yang akan diambil.
• Menghitung penyematan pribadi untuk pengambilan: jika prediksi pengambilan diperlukan, prediksi tersebut akan membuat panggilan terhadap layanan inferensi menggunakan fitur di atas, dan mendapatkan penyematan pribadi untuk prediksi waktu pengambilan.

prepareDataForAdRetrieval() akan menampilkan:

• Protected App Signals: payload sinyal yang diseleksi oleh teknologi iklan.
• Sinyal khusus lelang: sinyal sisi jual khusus platform, dan informasi kontekstual seperti auction_signals dan per_buyer_signals (termasuk penyematan kontekstual) dari SelectAdRequest. Hal ini persis seperti Protected Audience.
• Sinyal Tambahan: informasi tambahan seperti penyematan pribadi yang diambil dari layanan inferensi.

Permintaan ini dikirim ke Layanan Pengambilan Iklan, yang melakukan pencocokan kandidat, lalu menjalankan getCandidateAds() UDF.

UDF getCandidateAds()

getCandidateAds() berjalan pada Layanan Pengambilan Iklan. Metode ini menerima permintaan yang dibuat oleh prepareDataForAdRetrieval() pada layanan bidding pembeli. Layanan menjalankan getCandidateAds() yang mengambil kandidat top-k untuk bidding dengan mengonversi permintaan menjadi serangkaian kueri yang ditetapkan, pengambilan data, serta menjalankan logika bisnis kustom dan logika pengambilan kustom lainnya.

getCandidateAds() mengambil informasi berikut ini:

• Protected App Signals: payload sinyal yang diseleksi oleh teknologi iklan.
• Sinyal khusus lelang: sinyal sisi jual khusus platform, dan informasi kontekstual seperti auction_signals dan per_buyer_signals (termasuk penyematan kontekstual) dari SelectAdRequest. Hal ini persis seperti Protected Audience.
• Sinyal Tambahan: informasi tambahan seperti penyematan pribadi yang diambil dari layanan inferensi.

getCandidateAds() melakukan hal berikut ini:

1. Mengambil kumpulan awal kandidat iklan: Diambil menggunakan kriteria penargetan seperti bahasa, geografis, jenis iklan, ukuran iklan, atau anggaran, untuk memfilter kandidat iklan.
2. Mengambil penyematan pengambilan: Jika penyematan dari layanan nilai kunci diperlukan untuk membuat prediksi waktu pengambilan untuk pemilihan top k, penyematan tersebut harus diambil dari layanan nilai kunci.
3. Pemilihan kandidat top k: Hitung skor yang ringan untuk kumpulan kandidat iklan yang difilter berdasarkan metadata iklan yang diambil dari penyimpanan nilai kunci, dan informasi yang dikirim dari layanan bidding pembeli, serta untuk memilih kandidat top k berdasarkan skor tersebut. Misalnya, skornya mungkin berupa peluang menginstal aplikasi dengan mempertimbangkan iklan.
4. Pengambilan penyematan bidding: jika penyematan dari layanan nilai kunci diperlukan oleh kode bidding untuk membuat prediksi waktu bidding, penyematan dapat diambil dari layanan nilai kunci.

Perhatikan bahwa skor untuk iklan mungkin merupakan output dari model prediktif, yang misalnya memprediksi kemungkinan pengguna menginstal aplikasi. Jenis pembuatan skor ini melibatkan semacam faktorisasi model: karena getCandidateAds() berjalan pada Layanan Pengambilan Iklan, dan karena layanan pengambilan iklan tidak memiliki layanan inferensi, prediksi dapat dihasilkan dengan menggabungkan:

• Penyematan kontekstual yang diteruskan menggunakan input sinyal khusus lelang.
• Penyematan pribadi yang diteruskan menggunakan input sinyal tambahan.
• Semua teknologi iklan penyematan non pribadi telah terwujud dari server mereka ke layanan nilai kunci Layanan Pengambilan Iklan.

Perhatikan bahwa generateBid() UDF yang berjalan di layanan bidding pembeli juga dapat menerapkan jenis faktorisasi model sendiri untuk membuat prediksi bidding-nya. Jika diperlukan penyematan dari layanan nilai kunci untuk melakukannya, penyematan harus diambil sekarang.

getCandidateAds() akan menampilkan:

• Iklan kandidat: iklan top k yang akan diteruskan ke generateBid(). Setiap iklan terdiri dari:
  • URL Render: endpoint untuk merender materi iklan.
  • Metadata: metadata iklan khusus teknologi iklan sisi beli. Misalnya, metadata ini dapat menyertakan informasi tentang kampanye iklan, dan kriteria penargetan seperti lokasi dan bahasa. Metadata dapat mencakup penyematan opsional yang digunakan ketika faktorisasi model diperlukan untuk menjalankan inferensi selama bidding.
• Sinyal Tambahan: secara opsional, Layanan Pengambilan Iklan dapat menyertakan informasi tambahan seperti penyematan tambahan atau sinyal spam untuk digunakan di generateBid().

Kami sedang menyelidiki metode lain untuk menyediakan iklan yang akan diberi skor, termasuk menyediakannya sebagai bagian dari panggilan SelectAdRequest. Iklan ini dapat diambil menggunakan permintaan bid RTB. Perhatikan bahwa dalam kasus tersebut, iklan harus diambil tanpa Protected App Signals. Kami memperkirakan bahwa teknologi iklan akan mengevaluasi konsekuensinya sebelum memilih opsi yang terbaik, termasuk ukuran payload respons, latensi, biaya, dan ketersediaan sinyal.

UDF generateBid()

Setelah mengambil kumpulan iklan kandidat dan penyematan selama pengambilan, Anda siap untuk melanjutkan ke bidding, yang berjalan di layanan bidding pembeli. Layanan ini menjalankan generateBid() UDF yang disediakan pembeli untuk memilih iklan yang akan di-bidding dari top k, lalu menampilkannya bersama bid-nya.

generateBid() mengambil informasi berikut ini:

• Iklan kandidat: iklan top k yang ditampilkan oleh layanan Pengambilan Iklan.
• Sinyal khusus lelang: sinyal sisi jual khusus platform, dan informasi kontekstual seperti auction_signals dan per_buyer_signals (termasuk penyematan kontekstual) dari SelectAdRequest.
• Sinyal tambahan: informasi tambahan yang akan digunakan pada waktu bidding.

Penerapan generateBid() pembeli melakukan tiga hal sebagai berikut:

• Fiturisasi: mengubah sinyal menjadi fitur untuk digunakan selama inferensi.
• Inferensi: menghasilkan prediksi menggunakan model machine learning untuk menghitung nilai seperti prediksi rasio klik-tayang, dan rasio konversi.
• Bidding: menggabungkan nilai yang disimpulkan dengan input lain untuk menghitung bid bagi iklan kandidat.

generateBid() akan menampilkan:

• Iklan kandidat.
• Jumlah bid yang telah dihitung.

Perhatikan bahwa generateBid() yang digunakan untuk Iklan Instal Aplikasi dan yang digunakan untuk Iklan Pemasaran Ulang berbeda.

Bagian berikut ini menjelaskan fitur, inferensi, dan bidding secara lebih mendetail.

Fiturisasi

Sinyal lelang dapat disiapkan oleh generateBid() ke dalam fitur. Fitur-fitur ini dapat digunakan selama berlangsungnya inferensi untuk memprediksi hal-hal seperti rasio klik-tayang dan rasio konversi. Kami juga mempelajari mekanisme yang menjaga privasi untuk mengirimkan beberapa di antaranya dalam laporan kemenangan untuk digunakan dalam pelatihan model.

Inferensi

Saat menghitung bid, melakukan inferensi terhadap satu atau beberapa model machine learning adalah hal yang umum. Misalnya, penghitungan eCPM yang efektif sering kali menggunakan model untuk memprediksi rasio klik-tayang dan konversi.

Klien dapat menyediakan sejumlah model machine learning bersama dengan implementasi generateBid() mereka. Kami juga akan menyediakan JavaScript API dalam generateBid() agar klien dapat melakukan inferensi pada waktu proses.

Inferensi dijalankan pada layanan bidding pembeli. Hal ini dapat memengaruhi latensi dan biaya inferensi, terutama karena akseleratornya belum tersedia di TEE. Beberapa klien akan mendapati bahwa kebutuhan mereka terpenuhi dengan model individual yang berjalan di layanan bidding pembeli. Beberapa klien—misalnya klien dengan model yang sangat besar—mungkin ingin mempertimbangkan opsi seperti faktorisasi model untuk meminimalkan biaya inferensi dan latensi pada waktu bid.

Informasi selengkapnya tentang kemampuan inferensi seperti format model yang didukung dan ukuran maksimum akan diberikan dalam update mendatang.

Mengimplementasikan faktorisasi model

Sebelumnya, kami telah menjelaskan faktorisasi model. Pada waktu bidding, pendekatan spesifiknya adalah:

1. Pisahkan model tunggal menjadi bagian pribadi (data pengguna), dan satu atau beberapa bagian non pribadi (data kontekstual dan iklan).
2. Teruskan elemen non pribadi ke generateBid(). Metrik ini dapat berasal dari per_buyer_signals, atau dari penyematan yang dihitung oleh teknologi iklan secara eksternal, diwujudkan ke dalam penyimpanan nilai kunci layanan pengambilan, pengambilan pada waktu pengambilan, dan dikembalikan sebagai bagian dari sinyal. Ini tidak termasuk penyematan pribadi karena tidak dapat bersumber dari luar batas privasi.
3. Dalam generateBid():
   1. Lakukan inferensi terhadap model untuk mendapatkan penyematan pengguna pribadi.
   2. Gabungkan penyematan pengguna pribadi dengan penyematan kontekstual dari per_buyer_signals, atau iklan non pribadi dan penyematan kontekstual dari layanan pengambilan menggunakan operasi seperti produk titik. Ini adalah prediksi akhir yang dapat digunakan untuk menghitung bid.

Dengan pendekatan ini, Anda dapat melakukan inferensi pada waktu bidding terhadap model yang akan terlalu besar atau lambat untuk dijalankan di layanan bidding pembeli.

Logika penskoran sisi jual

Pada tahap ini, iklan dengan bid yang diterima dari semua pembeli yang berpartisipasi dinilai. Output generateBid() diteruskan ke layanan lelang penjual untuk menjalankan scoreAd(), dan bahwa scoreAd() hanya mempertimbangkan satu iklan dalam satu waktu. Berdasarkan penskoran tersebut, penjual memilih iklan pemenang untuk dikembalikan ke perangkat untuk dirender.

Logika penskorannya sama dengan yang digunakan untuk alur pemasaran ulang Protected Audience, dan dapat memilih pemenang di antara kandidat pemasaran ulang dan instal aplikasi. Fungsi ini dipanggil satu kali untuk setiap iklan kandidat yang dikirim di dalam Protected Auction. Lihat penjelasan Bidding dan Lelang untuk mengetahui detailnya.

Runtime kode pemilihan iklan

Dalam proposal, kode pemilihan iklan untuk penginstalan aplikasi ditentukan dengan cara yang sama seperti alur pemasaran ulang Protected Audience. Untuk mengetahui detailnya, lihat Konfigurasi Bidding dan Lelang. Kode bidding akan tersedia di dalam lokasi penyimpanan cloud yang sama dengan yang digunakan untuk pemasaran ulang.

Pelaporan

Proposal ini menggunakan Reporting API yang sama dengan proposal pelaporan Protected Audience (misalnya, reportImpression(), yang memicu platform untuk mengirim laporan penjual dan pembeli).

Salah satu kasus penggunaan umum untuk pelaporan di sisi beli adalah mendapatkan data pelatihan untuk model yang digunakan selama pemilihan iklan. Selain API yang ada, platform ini akan menyediakan mekanisme khusus untuk mengeluarkan data tingkat peristiwa dari platform ke server teknologi iklan. Payload keluar ini dapat mencakup data pengguna tertentu.

Dalam jangka panjang, kami menyelidiki solusi yang menjaga privasi untuk mengatasi pelatihan model dengan data yang digunakan di Protected Auction tanpa mengirimkan data pengguna tingkat peristiwa ke luar layanan yang berjalan di TEE. Kami akan memberikan detail tambahan dalam pembaruan selanjutnya.

Dalam jangka pendek, kami akan memberikan cara sementara untuk mengeluarkan data yang berisi derau dari generateBid(). Proposal awal kami untuk hal ini ada di bawah, dan kami akan mengembangkannya (termasuk kemungkinan perubahan yang tidak kompatibel dengan versi sebelumnya) sebagai respons terhadap masukan industri.

Secara teknis, cara kerjanya adalah:

1. Teknologi iklan menentukan skema untuk data yang ingin dikirim.
2. Di generateBid(), mereka membuat payload egress yang diinginkan.
3. Platform memvalidasi payload egress terhadap skema dan menerapkan batas ukuran.
4. Platform menambahkan derau ke payload keluar.
5. Payload keluar disertakan dalam laporan kemenangan dalam format wire, diterima di server teknologi iklan, didekode, dan digunakan untuk pelatihan model.

Menentukan skema payload egress

Agar platform dapat menerapkan persyaratan privasi yang terus berkembang, payload keluar harus disusun dengan cara yang dapat dipahami platform. Teknologi iklan akan menentukan struktur payload keluar dengan menyediakan file JSON skema. Skema tersebut akan diproses oleh platform, dan akan dirahasiakan oleh layanan Bidding dan Lelang menggunakan mekanisme yang sama dengan resource teknologi iklan lainnya seperti UDF dan model.

Kami akan menyediakan file CDDL yang menentukan struktur JSON tersebut. File CDDL akan menyertakan serangkaian jenis fitur yang didukung (misalnya, fitur yang berupa boolean, bilangan bulat, bucket, dan sebagainya). File CDDL dan skema yang disediakan akan diberi versi.

Misalnya, payload keluar yang terdiri dari satu fitur boolean yang diikuti dengan fitur bucket berukuran dua akan terlihat seperti ini:

egressPayload = {
  features : [
    {
      type: "boolean_feature",
      value: false
    },
    {
      type: "bucket_feature",
      size: 2,
      value: [
        {
          value: false
        },
        {
          value: true
        }
      ]
    }
  ]
}

Detail tentang kumpulan jenis fitur yang didukung tersedia di GitHub.

Membuat payload egress di generateBid()

Semua Protected App Signals untuk pembeli tertentu tersedia untuk UDF generateBid() mereka. Setelah fitur ini diaktifkan, teknologi iklan akan membuat payload dalam format JSON. Payload keluar ini akan disertakan dalam laporan kemenangan pembeli untuk transmisi ke server teknologi iklan.

Alternatif untuk desain ini adalah agar penghitungan vektor keluar terjadi di reportWin(), bukan generateBid(). Ada kompromi untuk setiap pendekatan, dan kami akan menyelesaikan keputusan ini sebagai respons terhadap masukan dari industri.

Memvalidasi payload egress

Platform ini akan memvalidasi payload keluar yang dibuat oleh teknologi iklan. Validasi memastikan bahwa nilai fitur valid untuk jenisnya, batasan ukuran terpenuhi, dan bahwa pelaku berbahaya tidak mencoba mengakali kontrol privasi dengan memasukkan informasi tambahan ke dalam payload keluar mereka.

Jika tidak valid, payload keluar akan dihapus secara otomatis dari input yang dikirim ke laporan kemenangan. Hal ini karena kami tidak ingin memberikan informasi proses debug kepada pihak tidak bertanggung jawab yang mencoba mengakali validasi.

Kami akan menyediakan JavaScript API untuk teknologi iklan guna memastikan payload keluar yang mereka buat di generateBid() akan lulus validasi platform:

validate(payload, schema)

JavaScript API ini sepenuhnya ditujukan untuk pemanggil guna menentukan apakah payload tertentu akan lulus validasi platform. Validasi sebenarnya harus dilakukan di platform untuk melindungi dari UDF generateBid() berbahaya.

Mengganggu payload keluar

Platform akan membuat derau pada payload keluar sebelum menyertakannya dalam laporan kemenangan. Nilai minimum derau awal akan menjadi 1%, dan nilai ini dapat berubah dari waktu ke waktu. Platform tidak akan memberikan indikasi apakah payload keluar tertentu telah diganggu atau tidak.

Metode derau adalah:

1. Platform memuat definisi skema untuk payload keluar.
2. 1% payload keluar akan dipilih untuk membuat derau.
3. Jika payload keluar tidak dipilih, seluruh nilai asli akan dipertahankan.
4. Jika payload keluar dipilih, setiap nilai fitur akan diganti dengan nilai valid acak untuk jenis fitur tersebut (misalnya, 0 atau 1 untuk fitur boolean).

Mengirim, menerima, dan mendekode payload keluar untuk pelatihan model

Payload egress yang divalidasi dan berisi derau akan disertakan dalam argumen ke reportWin(), dan dikirim ke server teknologi iklan pembeli di luar batas privasi untuk pelatihan model. Payload keluar akan dalam format wire.

Detail tentang format kabel untuk semua jenis fitur dan untuk payload egress itu sendiri tersedia di GitHub.

Menentukan ukuran payload egress

Ukuran payload keluar dalam bit menyeimbangkan utilitas dan minimalisasi data. Kami akan bekerja sama dengan industri untuk menentukan ukuran yang sesuai melalui eksperimen. Saat menjalankan eksperimen tersebut, kami akan sementara mengekspor data tanpa batasan ukuran bit. Data keluar tambahan tersebut tanpa batasan ukuran bit akan dihapus setelah eksperimen selesai.

Metode untuk menentukan ukuran adalah:

1. Awalnya, kami akan mendukung dua payload egress di generateBid():
   1. egressPayload: payload keluar dengan ukuran terbatas yang telah kami jelaskan sejauh ini dalam dokumen ini. Awalnya, ukuran payload egress ini akan menjadi 0 bit (artinya payload ini akan selalu dihapus selama validasi).
   2. temporaryUnlimitedEgressPayload: payload keluar sementara dengan ukuran tidak terbatas untuk eksperimen ukuran. Pemformatan, pembuatan, dan pemrosesan payload keluar ini menggunakan mekanisme yang sama dengan egressPayload.
2. Setiap payload keluar ini akan memiliki file JSON skema sendiri: egress_payload_schema.json dan temporary_egress_payload_schema.json.
3. Kami menyediakan protokol eksperimen dan kumpulan metrik untuk menentukan utilitas model pada berbagai ukuran payload keluar (misalnya, 5, 10, ... bit).
4. Berdasarkan hasil eksperimen, kami menentukan ukuran payload keluar dengan kompromi utilitas dan privasi yang tepat.
5. Kita menetapkan ukuran egressPayload dari 0 bit ke ukuran baru.
6. Setelah periode migrasi yang ditetapkan, kami akan menghapus temporaryUnlimitedEgressPayload, sehingga hanya menyisakan egressPayload dengan ukuran barunya.

Kami sedang menyelidiki pembatasan teknis tambahan untuk mengelola perubahan ini (misalnya, mengenkripsi egressPayload saat kami meningkatkan ukurannya dari 0 bit). Detail tersebut -- beserta pengaturan waktu untuk eksperimen dan penghapusan temporaryUnlimitedEgressPayload -- akan disertakan dalam update selanjutnya.

Selanjutnya, kami akan menjelaskan kemungkinan protokol eksperimen untuk menyelesaikan ukuran egressPayload. Tujuan kami adalah bekerja sama dengan industri untuk menemukan ukuran yang menyeimbangkan utilitas dan pengurangan data. Artefak yang akan dihasilkan oleh eksperimen ini adalah grafik dengan sumbu x adalah ukuran payload pelatihan dalam bit, dan sumbu y adalah persentase pendapatan yang dihasilkan oleh model pada ukuran tersebut dibandingkan dengan dasar pengukuran tanpa batas ukuran.

Kita akan mengasumsikan bahwa kita sedang melatih model pInstall, dan sumber data pelatihan kita adalah log dan konten temporaryUnlimitedegressPayload yang kita terima saat memenangkan lelang. Protokol untuk teknologi iklan pertama-tama melibatkan eksperimen offline:

1. Tentukan arsitektur model yang akan mereka gunakan dengan Protected App Signals. Misalnya, mereka harus menentukan apakah akan menggunakan faktorisasi model atau tidak.
2. Tentukan metrik untuk mengukur kualitas model. Metrik yang disarankan adalah kerugian AUC dan kerugian log.
3. Tentukan kumpulan fitur yang akan digunakan selama pelatihan model.
4. Dengan menggunakan arsitektur model, metrik kualitas, dan kumpulan fitur pelatihan tersebut, jalankan studi ablasi untuk menentukan utilitas yang dikontribusikan per bit untuk setiap model yang ingin digunakan di PAS. Protokol yang disarankan untuk studi ablasi adalah:
   1. Latih model dengan semua fitur dan ukur utilitasnya; ini adalah dasar pengukuran untuk perbandingan.
   2. Untuk setiap fitur yang digunakan untuk menghasilkan dasar pengukuran, latih model dengan semua fitur kecuali fitur tersebut.
   3. Ukur utilitas yang dihasilkan. Bagi delta dengan ukuran fitur dalam bit; ini adalah utilitas yang diharapkan per bit untuk fitur tersebut.
5. Tentukan ukuran payload pelatihan yang diinginkan untuk eksperimen. Sebaiknya gunakan [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit. Masing-masing mewakili kemungkinan ukuran untuk egressPayload yang akan dievaluasi oleh eksperimen.
6. Untuk setiap ukuran yang memungkinkan, pilih kumpulan fitur yang kurang dari atau sama dengan ukuran yang memaksimalkan utilitas per bit, menggunakan hasil studi ablasi.
7. Latih model untuk setiap kemungkinan ukuran dan evaluasi utilitasnya sebagai persentase utilitas model dasar pengukuran yang dilatih pada semua fitur.
8. Buat plot hasil pada grafik dengan sumbu x adalah ukuran payload pelatihan dalam bit, dan sumbu y adalah persentase pendapatan yang dihasilkan oleh model tersebut dibandingkan dengan dasar pengukuran.

Selanjutnya, teknologi iklan dapat mengulangi langkah 5-8 dalam eksperimen traffic live, menggunakan data fitur yang dikirim melalui temporaryUnlimitedEgressPayload. Teknologi iklan dapat memilih untuk membagikan hasil eksperimen traffic offline dan live mereka dengan Privacy Sandbox untuk menginformasikan keputusan tentang ukuran egressPayload.

Linimasa untuk eksperimen ini, serta linimasa untuk menetapkan ukuran egressPayload ke nilai yang dihasilkan, berada di luar cakupan dokumen ini dan akan hadir dalam update berikutnya.

Langkah-langkah perlindungan data

Kami akan menerapkan sejumlah perlindungan untuk data yang keluar, termasuk:

1. egressPayload dan temporaryUnlimitedEgressPayload akan berisi derau.
2. Untuk perlindungan dan pengurangan data, temporaryUnlimitedEgressPayload hanya akan tersedia selama durasi eksperimen ukuran, tempat kita akan menentukan ukuran yang benar untuk egressPayload.

Izin

Kontrol pengguna

• Proposal ini dimaksudkan untuk memberi pengguna visibilitas ke daftar aplikasi terinstal yang telah menyimpan setidaknya satu Protected App Signals, atau audiens kustom.
• Pengguna dapat memblokir dan menghapus aplikasi dari daftar ini. Pemblokiran dan penghapusan akan melakukan hal berikut ini:
  • Menghapus semua Protected App Signals dan audiens kustom yang terkait dengan aplikasi.
  • Mencegah aplikasi menyimpan Protected App Signals dan audiens kustom baru
• Pengguna dapat sepenuhnya mereset Protected App Signals dan Protected Audience API. Jika hal ini terjadi, semua Protected App Signals dan audiens kustom yang ada di dalam perangkat akan dihapus.
• Pengguna dapat memilih untuk sepenuhnya tidak ikut dari Privacy Sandbox di Android, yang mencakup Protected App Signals API dan Protected Audience API. Jika demikian, Protected Audience API dan Protected App Signals API menampilkan pesan pengecualian standar: SECURITY_EXCEPTION.

Izin dan kontrol aplikasi

Proposal ini dimaksudkan untuk memberikan kontrol kepada aplikasi atas Protected App Signals:

• Aplikasi dapat mengelola pengaitannya dengan Protected App Signals.
• Aplikasi dapat memberikan izin kepada platform teknologi iklan pihak ketiga untuk mengelola Protected App Signals atas namanya.

Kontrol platform teknologi iklan

Proposal ini menguraikan cara teknologi iklan mengontrol Protected App Signals:

• Semua teknologi iklan harus mendaftar ke Privacy Sandbox, dan memberikan domain "situs" atau "asal" yang cocok dengan semua URL untuk Protected App Signals.
• Teknologi iklan dapat berpartner dengan aplikasi atau SDK untuk memberikan token verifikasi yang digunakan untuk memverifikasi pembuatan Protected App Signals. Saat proses ini didelegasikan ke partner, pembuatan Protected App Signals dapat dikonfigurasi untuk memerlukan konfirmasi oleh teknologi iklan.