Halaman ini diterjemahkan oleh Cloud Translation API.

Sinyal Aplikasi yang Dilindungi untuk mendukung iklan instal aplikasi yang relevan

Proposal ini tunduk kepada proses pendaftaran Privacy Sandbox dan pengesahan. Untuk informasi lebih lanjut terkait pengesahan, lihat ke link pengesahan yang disediakan. Pembaruan di masa mendatang untuk 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:

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 aplikasi penginstalan, pertama dibuka, tindakan pengguna (peningkatan level dalam game, pencapaian), aktivitas pembelian, atau waktu dalam aplikasi. Sinyal ditulis dan disimpan di untuk melindungi dari kebocoran data, dan hanya disediakan untuk logika teknologi iklan yang menyimpan sinyal yang diberikan selama Protected Auction berjalan di lingkungan yang aman.
Ad Selection API: Layanan ini menyediakan API untuk mengonfigurasi dan menjalankan Protected Auction yang berjalan di Trusted Execution Environment (TEE) di mana teknologi iklan mengambil kandidat iklan, menjalankan inferensi, menghitung bid, dan penskoran untuk memilih “pemenang” menggunakan Protected App Signals, dan informasi kontekstual real-time yang diberikan penayang.

Diagram yang menunjukkan alur penginstalan aplikasi dengan sinyal terlindungi — Diagram alir yang menunjukkan Protected App Signals dan alur kerja pemilihan iklan pada Privacy Sandbox di Android.

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 mode yang dilindungi di perangkat penyimpanan, serupa dengan Audiens Kustom, dan dienkripsi sebelum dikirim dari perangkat sehingga hanya layanan Bidding dan Lelang yang berjalan dalam Trusted Execution Environment dengan keamanan dan privasi dapat mendekripsinya untuk iklan bidding dan penskoran.
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 untuk menghasilkan payload Protected App Signals yang nantinya dapat digunakan secara real-time untuk pemilihan iklan selama periode Lelang. Payload tersebut disimpan dengan aman di perangkat hingga dikirimkan untuk lelang.
Pemilihan Iklan: Untuk memilih iklan yang relevan bagi pengguna, SDK penjual mengirimkan payload terenkripsi Protected App Signals, dan mengonfigurasi Protected Auction. Dalam lelang, logika kustom pembeli menyiapkan mekanisme App Signals beserta data kontekstual yang diberikan penayang (data yang biasanya dibagikan dalam permintaan iklan RTB Terbuka) untuk merancang fitur yang ditujukan untuk pemilihan iklan (pengambilan iklan, inferensi, dan bid sebelumnya). 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 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: iklan skor logika penskoran kustom dikirim oleh Pembeli yang berpartisipasi dan memilih iklan pemenang untuk dikirim kembali ke aplikasi untuk rendering.
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

	Pratinjau Developer			Beta
Fitur	Q4'23	Q1'24	Q2'24	Q3'24
API Seleksi Sinyal	API penyimpanan di perangkat	Logika kuota penyimpanan di perangkat Pembaruan harian logika kustom di perangkat	T/A	Tersedia untuk Perangkat 1% T+
Server pengambilan iklan di TEE	MVP	Tersedia di GCP Dukungan untuk Top-K produksi UDF	Tersedia di AWS Proses Debug, Metrik, dan Monitoring yang Diizinkan
Layanan Inferensi di TEE Dukungan untuk menjalankan model ML dan menggunakannya untuk bidding di TEE	Dalam Pengembangan	Tersedia di GCP Kemampuan untuk men-deploy & membuat prototipe model ML statis menggunakan Tensorflow dan PyTorch	Tersedia di AWS Deployment model yang diproduksi untuk model Tensorflow dan PyTorch Telemetry, Proses Debug yang Diizinkan, dan Monitoring
Dukungan Bidding dan Lelang di TEE	Tersedia di GCP	Integrasi Pengambilan Iklan PAS-B&A dan TEE (dengan enkripsi gRPC dan TEE<>TEE) Dukungan Pengambilan Iklan melalui jalur kontekstual (mencakup dukungan B&A<>K/V di TEE)	Tersedia di AWS Pelaporan debug Proses Debug, Metrik, dan Monitoring yang Diizinkan

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 dalam aplikasi. Protected App Signals disimpan dengan aman di perangkat, dan dienkripsi sebelum dikirim dari perangkat sehingga hanya Bidding dan Lelang layanan yang berjalan dalam Trusted Execution Environment dengan keamanan yang sesuai dan kontrol privasi dapat membongkar enkripsinya untuk proses 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 mempersiapkannya untuk rekayasa fitur lebih lanjut secara real time selama berlangsungnya Protected Auction dalam 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() menggunakan URI dan mengambil daftar pembaruan sinyal. Sebagai ilustrasi, fetchSignalUpdates() mengeluarkan permintaan GET ke URI yang 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 bermanfaat misalnya untuk menyetel ID eksperimen untuk pengguna tertentu dan menghindari penggantian jika sudah yang ditetapkan oleh aplikasi lain.
add: menambahkan elemen ke deret waktu yang terkait dengan kunci yang diberikan. Parameter maxSignals menentukan jumlah sinyal maksimum dalam waktu Workspace kami. Jika ukurannya terlampaui, elemen sebelumnya akan dihapus. Jika kunci berisi nilai skalar yang secara 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 tersimpan secara otomatis dikaitkan dengan aplikasi yang melakukan permintaan pengambilan, dan responden 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.

Ilustrasi alur kerja pemilihan iklan. — Alur kerja pemilihan iklan di Privacy Sandbox di Android.

Alur kerja pemilihan iklan adalah sebagai berikut:

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

Memulai alur kerja pemilihan iklan

Saat aplikasi siap menampilkan iklan, SDK teknologi iklan (biasanya SSP) memulai alur kerja pemilihan iklan dengan mengirimkan data kontekstual yang relevan dari penayang dan payload terenkripsi per pembeli untuk disertakan dalam permintaan dikirim ke Protected Auction menggunakan panggilan getAdSelectionData. Ini adalah API yang sama yang digunakan untuk alur kerja pemasaran ulang dan dijelaskan dalam panduan Proposal Integrasi 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 pembeli sinyal)
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.

Ilustrasi logika eksekusi pemilihan iklan sisi beli. — Logika eksekusi pemilihan iklan sisi beli di Privacy Sandbox di Android.

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.

Layanan BuyerFrontEnd menerima permintaan iklan.
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 opsi Pengambilan Iklan Layanan. Layanan bidding mengirimkan permintaan ini ke pengambilan yang dikonfigurasi endpoint server.
Layanan Pengambilan Iklan menjalankan getCandidateAds() UDF, yang memfilter hingga ke kumpulan iklan kandidat top k, yang dikirim ke layanan bidding.
Layanan bidding pembeli menjalankan generateBid() UDF, yang memilih kandidat terbaik, menghitung bid-nya, lalu menampilkannya ke layanan BuyerFrontEnd.
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:

Pisahkan model menjadi bagian pribadi (data pengguna), dan satu atau beberapa bagian non pribadi (data kontekstual dan iklan).
Secara opsional, teruskan beberapa atau semua bagian non pribadi sebagai argumen ke UDF yang perlu untuk membuat prediksi. Misalnya, embedding kontekstual diteruskan ke UDF di per_buyer_signals.
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.
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.

`prepareDataForAdRetrieval()` UDF

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.
Sinyal kontekstual auction_signals (untuk info tentang lelang) dan buyer_signals (untuk pembeli sinyal).

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, fungsi ini akan melakukan panggilan terhadap layanan inferensi menggunakan metode fitur, dan mendapatkan embedding 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.

`getCandidateAds()` UDF

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:

Mengambil kumpulan awal kandidat iklan: Diambil menggunakan kriteria penargetan seperti bahasa, geografis, jenis iklan, ukuran iklan, atau anggaran, untuk memfilter kandidat iklan.
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.
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.
Pengambilan penyematan bidding: jika penyematan dari layanan nilai kunci yang diperlukan oleh kode bidding untuk membuat prediksi waktu bidding, bid tersebut mungkin yang 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 sinyal khusus lelang input teks.
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, dapat menyertakan informasi tentang kampanye iklan, dan kriteria penargetan seperti lokasi dan bahasa. Metadata dapat mencakup opsi embedding yang digunakan ketika faktorisasi model diperlukan untuk menjalankan selama bidding.
Sinyal Tambahan: secara opsional, Layanan Pengambilan Iklan dapat mencakup 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.

`generateBid()` UDF

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 untuk 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 inferensi untuk memprediksi hal-hal seperti klik-tayang dan tingkat 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:

Pisahkan model tunggal menjadi bagian pribadi (data pengguna), dan satu atau beberapa bagian non pribadi (data kontekstual dan iklan).
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.
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

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

Pelaporan

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

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

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

Dalam jangka pendek, kami akan menyediakan cara sementara untuk mengeluarkan data yang bising keluar 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.

Secara teknis, cara kerjanya adalah:

Teknologi iklan menentukan skema untuk data yang ingin dikirim.
Di generateBid(), mereka mem-build payload keluar yang diinginkan.
Platform memvalidasi payload keluar terhadap skema dan menerapkan batas ukuran.
Platform menambahkan derau ke payload keluar.
Payload traffic keluar disertakan di laporan kemenangan dalam format wire, yang diterima pada server teknologi iklan, didekode, dan digunakan untuk pelatihan model.

Menentukan skema payload keluar

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

Kita akan menyediakan file CDDL yang menentukan struktur JSON tersebut. Tujuan File CDDL akan menyertakan serangkaian jenis fitur yang didukung (misalnya, fitur yaitu boolean, bilangan bulat, bucket, dan sebagainya). Baik file CDDL maupun skema yang diberikan akan dibuat versinya.

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

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

Detail mengenai serangkaian jenis fitur yang didukung tersedia di GitHub.

Membangun payload keluar di `generateBid()`

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

Alternatif untuk desain ini adalah perhitungan vektor keluar yang terjadi di reportWin(), bukan generateBid(). Ada konsekuensi untuk setiap dan kami akan memfinalisasikan keputusan ini sebagai tanggapan atas masukan dari industri.

Memvalidasi payload keluar

Platform akan memvalidasi setiap payload keluar yang dibuat oleh teknologi iklan. Validasi memastikan bahwa nilai fitur valid untuk tipenya, batasan ukuran terpenuhi, dan bahwa pelaku kejahatan tidak berusaha mengalahkan kontrol privasi dengan memasukkan informasi tambahan ke dalam payload traffic keluar.

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

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

validate(payload, schema)

JavaScript API ini sepenuhnya digunakan pemanggil untuk menentukan apakah payload tertentu akan lolos validasi platform. Validasi yang sebenarnya harus dilakukan di platform untuk melindungi Anda dari generateBid() UDF yang berbahaya.

Membuat derau pada payload keluar

Platform akan mendeteksi payload keluar sebelum menyertakannya dalam laporan kemenangan. Batas derau awal adalah 1%, dan nilai ini dapat berubah dari waktu ke waktu. Tujuan platform tidak akan memberikan indikasi apakah payload keluar tertentu atau tidak telah dibunyikan.

Metode derau adalah:

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

Mengirim, menerima, dan mendekode payload keluar untuk pelatihan model

Payload keluar yang divalidasi dan bersuara akan disertakan dalam argumen untuk reportWin(), dan dikirimkan ke server teknologi iklan pembeli di luar privasi untuk pelatihan model. Payload keluar akan dalam format kabel.

Detail tentang format wire untuk semua jenis fitur dan untuk payload traffic keluar sendiri tersedia di GitHub.

Menentukan ukuran payload keluar

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

Metode untuk menentukan ukuran adalah:

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

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

Selanjutnya kami akan menjelaskan protokol eksperimen yang mungkin untuk menyelesaikan ukuran egressPayload. Tujuan kami adalah bekerja sama dengan industri untuk menemukan ukuran yang seimbang utilitas dan minimalisasi data. Artefak yang akan dihasilkan eksperimen ini adalah grafik di mana sumbu x adalah ukuran {i>payload<i} pelatihan dalam bit, dan sumbu y adalah persentase pendapatan yang dihasilkan oleh model pada ukuran tersebut dibandingkan ke dasar pengukuran yang tidak terbatas.

Kita akan berasumsi bahwa kita melatih model pInstall, dan sumber data pelatihan adalah log dan isi temporaryUnlimitedegressPayload yang kita terima saat kita memenangkan lelang. Protokol untuk teknologi iklan terlebih dahulu melibatkan interaksi offline eksperimen:

Menentukan arsitektur model yang akan mereka gunakan dengan Protected App Sinyal. Misalnya, mereka perlu menentukan apakah mereka akan gunakan faktorisasi model.
Tentukan metrik untuk mengukur kualitas model. Metrik yang disarankan adalah kerugian AUC dan hilangnya log.
Menentukan serangkaian fitur yang akan mereka gunakan selama pelatihan model.
Dengan menggunakan arsitektur model, metrik kualitas, dan serangkaian fitur pelatihan, jalankan studi ablasi untuk menentukan kontribusi utilitas per bit untuk setiap yang ingin mereka gunakan di PAS. Protokol yang disarankan untuk studi ablasi adalah:
1. Melatih model dengan semua fitur dan mengukur utilitas; ini adalah dasar untuk perbandingan.
2. Untuk setiap fitur yang digunakan dalam menghasilkan dasar pengukuran, latih model dengan semua fitur kecuali fitur tersebut.
3. Mengukur utilitas yang dihasilkan. Bagi delta dengan ukuran fitur dalam bit; ini adalah utilitas per bit yang diharapkan untuk fitur tersebut.
Menentukan ukuran payload pelatihan yang diinginkan untuk eksperimen. Rab menyarankan [5, 10, 15, ..., size_of_all_training_features_for_baseline] bit. Masing-masing mewakili kemungkinan ukuran untuk egressPayload yang eksperimen akan dievaluasi.
Untuk setiap ukuran yang memungkinkan, pilih rangkaian fitur yang kurang dari atau sama dengan itu yang memaksimalkan utilitas per bit, dengan menggunakan hasil studi ablasi.
Latih sebuah model untuk setiap kemungkinan ukuran dan evaluasi utilitasnya sebagai persentase utilitas model dasar pengukuran yang dilatih pada semua fitur.
Petakan hasilnya pada grafik dengan sumbu x adalah ukuran pelatihan {i>payload<i} 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 fitur data yang dikirim melalui temporaryUnlimitedEgressPayload. Teknologi iklan dapat memilih untuk membagikan hasil eksperimen traffic offline dan live dengan Privacy Sandbox untuk menginformasikan keputusan tentang ukuran egressPayload.

Garis waktu{i> <i}untuk eksperimen ini, serta garis waktu{i> <i}untuk menetapkan ukuran dari egressPayload dengan nilai yang dihasilkan, berada di luar cakupan dokumen ini dan akan hadir dalam update selanjutnya.

Tindakan perlindungan data

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

egressPayload dan temporaryUnlimitedEgressPayload akan berbunyi.
Untuk perlindungan dan minimalisasi data, temporaryUnlimitedEgressPayload akan hanya tersedia selama durasi eksperimen ukuran, yaitu saat kami menentukan ukuran yang tepat 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 ini terjadi, semua Aplikasi Terlindungi yang sudah ada Sinyal dan audiens kustom di 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.