Sinyal Aplikasi yang Dilindungi untuk mendukung iklan instal aplikasi yang relevan

Proposal ini tunduk pada proses pendaftaran dan pengesahan Privacy Sandbox. Untuk mengetahui informasi lebih lanjut terkait pengesahan ini, buka link pengesahan yang disediakan. Update 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:

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, pertama dibuka, tindakan pengguna (level dalam game, pencapaian), aktivitas pembelian, atau waktu dalam aplikasi. Sinyal ditulis dan disimpan di perangkat untuk melindungi dari kebocoran data, dan hanya tersedia untuk logika teknologi iklan yang menyimpan sinyal tertentu selama Lelang Terlindungi berjalan di lingkungan yang aman.
2. Ad Selection API: API ini menyediakan API untuk mengonfigurasi dan menjalankan Lelang Terlindungi yang berjalan di Trusted Execution Environment (TEE) tempat teknologi iklan mengambil kandidat iklan, menjalankan inferensi, menghitung bid, dan melakukan penskoran untuk memilih iklan yang "pemenang" menggunakan Sinyal Aplikasi Terlindungi dan informasi kontekstual real-time yang diberikan 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 terlindungi, mirip dengan Audiens Kustom, dan dienkripsi sebelum dikirim keluar perangkat sehingga hanya layanan Bidding dan Lelang yang berjalan dalam Lingkungan Eksekusi Tepercaya dengan kontrol privasi dan keamanan yang sesuai yang dapat mendekripsinya untuk iklan bidding dan penskoran.
• Encoding Sinyal: Sinyal disiapkan sesuai ritme yang terjadwal oleh logika teknologi iklan kustom. Tugas latar belakang Android menjalankan logika ini untuk melakukan encoding di perangkat guna menghasilkan payload Sinyal Aplikasi yang Dilindungi yang nantinya dapat digunakan secara real-time untuk pemilihan iklan selama Lelang Terlindungi. Payload disimpan dengan aman di perangkat hingga dikirim untuk lelang.
• Pemilihan Iklan: Untuk memilih iklan yang relevan bagi pengguna, SDK penjual mengirimkan payload terenkripsi Sinyal Aplikasi yang Dilindungi dan mengonfigurasi Lelang Dilindungi. Dalam lelang, logika kustom pembeli menyiapkan Sinyal Aplikasi Terlindungi bersama dengan data kontekstual yang disediakan penayang (data biasanya dibagikan dalam permintaan iklan Open-RTB) untuk merancang fitur yang ditujukan untuk pemilihan iklan (pengambilan iklan, inferensi, dan pembuatan bid). Serupa dengan Protected Audience, pembeli mengirimkan iklan ke penjual untuk penskoran akhir di Protected Auction.
  • Pengambilan Iklan: Pembeli menggunakan Sinyal Aplikasi yang Dilindungi dan data kontekstual yang disediakan penayang untuk fitur engineer yang relevan dengan minat pengguna. Fitur ini digunakan untuk mencocokkan iklan yang memenuhi kriteria penargetan. Iklan yang tidak sesuai dengan anggaran akan dikecualikan. Iklan k teratas 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 penjual memberi skor pada iklan yang dikirimkan 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

	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 Sinyal Aplikasi yang Dilindungi yang ditentukan oleh teknologi iklan berdasarkan aktivitas pengguna, seperti pembukaan aplikasi, pencapaian, aktivitas pembelian, atau waktu dalam aplikasi. Sinyal Aplikasi yang Dilindungi disimpan dengan aman di perangkat, dan dienkripsi sebelum dikirim keluar dari perangkat sehingga hanya layanan Bidding dan Lelang yang berjalan dalam Lingkungan Eksekusi Tepercaya dengan kontrol privasi dan keamanan yang sesuai yang dapat mendekripsinya untuk iklan bidding dan penskoran. 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 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 Lelang Terlindungi 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 tertentu untuk mengambil daftar update 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 untuk pengguna tertentu dan menghindari penggantiannya 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 kunci berisi nilai skalar, kunci tersebut 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 disimpan 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.

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 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 untuk dikirim ke Lelang Terlindungi 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 yang 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 mengirim permintaan ke layanan bidding pembeli. Layanan bidding pembeli menjalankan UDF yang disebut prepareDataForAdRetrieval(), yang membuat permintaan untuk mendapatkan kandidat k teratas dari Layanan Pengambilan Iklan. Layanan bidding mengirimkan permintaan ini ke endpoint server pengambilan yang dikonfigurasi.
3. Layanan Pengambilan Iklan menjalankan UDF getCandidateAds(), yang memfilter hingga ke kumpulan iklan kandidat k teratas, 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, embedding kontekstual diteruskan ke UDF di 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 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 embeddings pribadi untuk pengambilan: jika prediksi pengambilan diperlukan, fitur ini akan melakukan panggilan terhadap layanan inferensi menggunakan fitur di atas, 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.

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 embedding dari layanan nilai kunci diperlukan oleh kode bidding untuk membuat prediksi waktu bidding, embedding 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:

• Embedding kontekstual yang diteruskan menggunakan input sinyal khusus lelang.
• Penyematan pribadi yang diteruskan menggunakan input sinyal tambahan.
• Teknologi iklan embedding 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 mencakup informasi tentang kampanye iklan, dan kriteria penargetan seperti lokasi dan bahasa. Metadata dapat menyertakan embedding opsional yang digunakan saat faktorisasi model diperlukan untuk menjalankan inferensi selama bidding.
• Sinyal Tambahan: secara opsional, Layanan Pengambilan Iklan dapat menyertakan informasi tambahan seperti embedding 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:

• Featurization: mengubah sinyal menjadi fitur yang akan 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 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 ini dapat digunakan selama inferensi untuk memprediksi hal-hal seperti 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. Di 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 ini, 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 lokasi penyimpanan cloud yang sama dengan kode yang digunakan untuk pemasaran ulang.

Pelaporan

Proposal ini menggunakan API pelaporan 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 tentang sisi beli adalah mendapatkan data pelatihan untuk model yang digunakan selama pemilihan iklan. Selain API yang sudah ada, platform akan menyediakan mekanisme spesifik untuk mengeluarkan data tingkat peristiwa dari platform ke server teknologi iklan. Payload traffic keluar ini dapat mencakup data pengguna tertentu.

Dalam jangka panjang, kami menyelidiki solusi yang menjaga privasi untuk menangani pelatihan model dengan data yang digunakan di Lelang Terlindungi tanpa mengirim data pengguna tingkat peristiwa di luar layanan yang berjalan di TEE. Kami akan memberikan detail tambahan dalam pemberitahuan selanjutnya.

Dalam jangka pendek, kami akan menyediakan cara sementara untuk mengeluarkan data dengan 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 dari industri.

Secara teknis, cara kerjanya adalah:

1. Teknologi iklan menentukan skema untuk data yang ingin dikirim.
2. Pada generateBid(), mereka mem-build payload traffic keluar yang diinginkan.
3. Platform ini memvalidasi payload keluar terhadap skema dan menerapkan batas ukuran.
4. Platform menambahkan derau ke payload keluar.
5. Payload traffic keluar disertakan dalam laporan menang dalam format kabel, diterima di server teknologi iklan, didekode, dan digunakan untuk pelatihan model.

Menentukan skema payload keluar

Agar platform dapat menegakkan persyaratan privasi yang terus berubah, payload traffic keluar harus distrukturkan dengan cara yang dapat dipahami oleh platform. Teknologi iklan akan menentukan struktur payload traffic keluar mereka dengan menyediakan file JSON skema. Skema tersebut akan diproses oleh platform, dan akan dijaga kerahasiaannya oleh layanan Bidding dan Lelang menggunakan mekanisme yang sama dengan resource teknologi iklan lainnya seperti UDF dan model.

Kami akan memberikan file CDDL yang menentukan struktur JSON tersebut. File CDDL akan mencakup sekumpulan jenis fitur yang didukung (misalnya, fitur yang berupa boolean, bilangan bulat, bucket, dan sebagainya). Baik file CDDL maupun skema yang diberikan akan diberi versi.

Misalnya, payload traffic keluar yang terdiri dari fitur boolean tunggal 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.

Buat payload traffic keluar di generateBid()

Semua Sinyal Aplikasi yang Dilindungi untuk pembeli tertentu tersedia untuk UDF generateBid() mereka. Setelah disiapkan, teknologi iklan akan membuat payload-nya dalam format JSON. Payload traffic keluar ini akan disertakan dalam laporan kemenangan pembeli untuk transmisi ke server teknologi iklan.

Alternatif untuk desain ini adalah penghitungan vektor keluar yang dilakukan di reportWin(), bukan generateBid(). Ada kompromi untuk setiap pendekatan, dan kami akan menyelesaikan keputusan ini sebagai tanggapan atas masukan industri.

Memvalidasi payload traffic keluar

Platform akan memvalidasi semua payload traffic keluar yang dibuat oleh teknologi iklan. Validasi memastikan nilai fitur valid untuk jenisnya, batasan ukuran terpenuhi, dan pelaku kejahatan tidak mencoba mengalahkan kontrol privasi dengan mengemas informasi tambahan ke dalam payload traffic keluar mereka.

Jika payload traffic keluar tidak valid, payload tersebut akan dihapus secara diam-diam dari input yang dikirim ke laporan menang. Hal ini karena kami tidak ingin memberikan informasi proses debug kepada pihak tidak bertanggung jawab yang mencoba mengalahkan 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 bagi pemanggil untuk menentukan apakah payload tertentu akan lulus validasi platform atau tidak. Validasi aktual harus dilakukan di platform untuk mencegah UDF generateBid() berbahaya.

Lakukan derau pada payload traffic keluar

Platform akan mencari payload traffic keluar sebelum menyertakannya dalam laporan kemenangan. Nilai minimum derau awal adalah 1%, dan nilai ini dapat berubah dari waktu ke waktu. Platform tidak akan memberikan indikasi apakah payload keluar tertentu telah di-noise atau tidak.

Metode derau adalah:

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

Mengirimkan, menerima, dan mendekode payload traffic keluar untuk pelatihan model

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

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

Menentukan ukuran payload keluar

Ukuran payload traffic 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, untuk sementara kami akan melihat data tanpa batasan ukuran bit. Data traffic keluar tambahan tersebut tanpa batasan ukuran bit akan dihapus setelah eksperimen selesai.

Metode untuk menentukan ukuran adalah:

1. Awalnya, kami akan mendukung dua payload traffic keluar di generateBid():
   1. egressPayload: payload keluar dengan ukuran terbatas yang telah kami jelaskan sejauh ini dalam dokumen ini. Awalnya, ukuran payload traffic keluar ini adalah 0 bit (artinya akan selalu dihapus selama validasi).
   2. temporaryUnlimitedEgressPayload: payload traffic keluar tanpa batas sementara untuk eksperimen ukuran. Pemformatan, pembuatan, dan pemrosesan payload keluar ini menggunakan mekanisme yang sama dengan egressPayload.
2. Setiap payload traffic keluar ini akan memiliki file JSON skemanya 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 traffic keluar dengan kompromi utilitas dan privasi yang tepat.
5. Kami menetapkan ukuran egressPayload dari 0 bit ke ukuran baru.
6. Setelah periode migrasi yang ditetapkan, kami menghapus temporaryUnlimitedEgressPayload, sehingga hanya menyisakan egressPayload dengan ukuran barunya.

Kami sedang menyelidiki batasan teknis tambahan untuk mengelola perubahan ini (misalnya, mengenkripsi egressPayload saat kami meningkatkan ukurannya dari 0 bit). Detail tersebut, bersama dengan informasi tambahan seperti protokol eksperimen, waktu eksperimen, dan waktu penghapusan temporaryUnlimitedEgressPayload, akan disertakan dalam pembaruan selanjutnya.

Tindakan perlindungan data

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

1. egressPayload dan temporaryUnlimitedEgressPayload akan dibunyikan.
2. Untuk minimalisasi dan perlindungan data, temporaryUnlimitedEgressPayload hanya akan tersedia selama durasi eksperimen ukuran, saat 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 Sinyal Aplikasi yang Dilindungi 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 Sinyal Aplikasi Terlindungi dan audiens kustom yang ada 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 sinyal Aplikasi yang Dilindungi atas nama aplikasi tersebut.

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 Sinyal Aplikasi yang Dilindungi. Saat proses ini didelegasikan ke partner, pembuatan Protected App Signals dapat dikonfigurasi untuk memerlukan konfirmasi oleh teknologi iklan.