Layanan Bidding dan Lelang

Dalam proposal awal Protected Audience, bidding dan lelang untuk permintaan iklan pemasaran ulang dijalankan secara lokal di perangkat. Persyaratan ini mungkin menuntut persyaratan komputasi yang mungkin tidak praktis untuk dijalankan di perangkat dengan daya pemrosesan yang terbatas, atau mungkin terlalu lambat untuk memilih dan merender iklan karena latensi jaringan.

Proposal layanan Bidding dan Lelang (B&A) menguraikan cara untuk mengizinkan komputasi Protected Audience berlangsung di server cloud di trusted execution environment (TEE), bukan berjalan secara lokal di perangkat pengguna. Proposal B&A bertujuan untuk mendukung alur terpadu guna mempertimbangkan permintaan iklan kontekstual dan pemasaran ulang. Memindahkan komputasi ke server dapat membantu mengoptimalkan lelang Protected Audience dengan mengosongkan siklus komputasi dan bandwidth jaringan untuk perangkat.

Google akan menyediakan komponen B&A, dan komponen itu akan tersedia sebagai open source. Teknologi iklan yang tertarik dapat menghosting instance-nya sendiri dengan penyedia cloud publik yang didukung. Anda dapat membaca proposal B&A lebih lanjut di GitHub. Perhatikan bahwa tanggal yang ditampilkan dalam dokumen tersebut mencerminkan penerapan untuk Chrome, dan kami akan memublikasikan informasi selengkapnya tentang integrasi dengan Android di masa mendatang. Dokumen ini berfungsi sebagai pengantar B&A, dan API baru yang akan disediakan Android untuk berinteraksi dengan B&A. Kami akan memposting informasi teknis selengkapnya tentang cara menggunakan API baru ini dalam update mendatang.

Tempat layanan B&A sesuai

B&A memberikan opsi tambahan untuk menjalankan lelang di dalam server tepercaya yang dimiliki teknologi iklan yang menjalankan biner open source yang disediakan Google. Data pengguna tetap ada di perangkat, dan Google akan menyediakan API untuk memindahkan data tersebut dengan aman ke TEE. Informasi selengkapnya tentang strategi enkripsi kami dapat Anda temukan di bawah.

Artinya, beberapa bagian proses lelang terjadi di perangkat, dan bagian lainnya di cloud. Dari perspektif DSP, audiens kustom (termasuk iklan kandidat yang disertakan untuk kampanye pemasaran ulang) masih dikelola di perangkat menggunakan API pengelolaan audiens kustom yang sama dengan saat lelang dijalankan di perangkat. Dari sudut pandang SSP, permintaan tetap dipicu di perangkat, dan dokumen ini menjelaskan API baru yang akan digunakan. Untuk semua pihak, pelaporan hasil lelang masih dimulai dari perangkat, setelah panggilan B&A selesai.

Perbedaan utamanya terletak pada tempat logika pembuatan URL bidding, penskoran, dan pelaporan dijalankan. Alih-alih menjalankan logika bidding, lelang, dan pelaporan di perangkat, logika generateBid(), scoreAd(), reportResult(), dan reportWin() dijalankan di TEE. Logika bidding pembeli dan logika penskoran penjual dijalankan dalam lingkungan B&A mereka sendiri, di tengah alur lelang Protected Audience:

Ilustrasi yang menampilkan alur lelang Protected Audience dan tempat bidding dan lelang sesuai.
Alur lelang Protected Audience

Enkripsi Data

Dengan B&A, informasi Protected Audience seperti audiens kustom dan jumlah bid mengalir dari perangkat, melalui server teknologi iklan penjual, menuju ke server teknologi iklan pembeli, dan kembali ke perangkat. Oleh karena itu, platform ini mengenkripsi data yang menuju ke layanan Protected Audience, dan hanya dapat didekripsi oleh layanan yang telah disahkan. Baca selengkapnya tentang strategi enkripsi di GitHub.

Alur arsitektur dan lelang

Proposal ini mencakup kebutuhan beberapa komponen baru yang dijelaskan di GitHub, termasuk aliran data dari perangkat ke B&A.

Ilustrasi yang menampilkan alur lelang protected audience yang kontekstual dan terpadu, yang akan dijelaskan berikutnya.
Kontekstual &terpadu Alur lelang Protected Audience, dengan layanan bidding dan lelang.

Pada level tinggi, aliran data dijelaskan sebagai berikut:

  1. Di perangkat, penjual akan mengumpulkan informasi dari Protected Audience menggunakan getAdSelectionData API.
  2. SDK di perangkat mengirim permintaan ke layanan Iklan Penjual. Permintaan ini mencakup payload kontekstual dan ProtectedAudienceInput terenkripsi.
  3. Layanan Iklan Penjual mengirimkan permintaan ke layanan bidding real-time (RTB) pembeli yang berjalan di luar TEE untuk mendapatkan iklan kontekstual kandidat, lalu memberi skor dan memilih iklan kontekstual pemenang.
  4. Layanan Iklan Penjual mengirim permintaan ke layanan SellerFrontEnd miliknya yang berjalan di TEE.
  5. Layanan SellerFrontEnd mengirim permintaan dengan data khusus pembeli ke Layanan BuyerFrontEnd.
  6. Pembeli menggunakan layanan Kunci/Nilai dan layanan Bidding mereka sendiri, yang menghasilkan bid untuk kandidat iklan yang bersumber dari perangkat untuk semua audiens kustom yang dipertimbangkan untuk pemasaran ulang.
  7. Layanan SellerFrontEnd membaca dari layanan Kunci/Nilai mereka dan menilai iklan kandidat. Hasilnya dienkripsi dan ditampilkan ke layanan Iklan Penjual.
  8. Layanan Iklan Penjual menampilkan hasil pemenang yang dienkripsi, dan hasil kontekstual secara opsional, ke SDK di perangkat.
  9. Di perangkat, penjual mengambil iklan pemenang menggunakan processAdSelectionResult API, yang mendekripsi respons dari layanan Iklan Penjual.

Deskripsi mendetail tentang setiap langkah dan cara data dienkripsi dapat ditemukan di GitHub. Kode untuk komponen ini akan tersedia melalui open source. Kode yang disediakan akan menangani penggabungan permintaan dari layanan SellerFrontEnd ke layanan BuyerFrontEnd.

Deployment Cloud

Teknologi iklan akan men-deploy layanan B&A ke platform cloud publik yang didukung. Deployment ini akan dikelola oleh teknologi iklan yang akan bertanggung jawab untuk menentukan Tujuan Tingkat layanan ketersediaan.

Menjalankan lelang

Langkah pertama untuk menjalankan lelang B&A adalah mengumpulkan data dari audiens kustom di perangkat dan mengenkripsinya untuk dikirim ke lelang sisi server. Untuk melakukannya, gunakan getAdSelectionData API:

AdSelectionData getAdSelectionData(AdTechIdentifier seller)

Metode getAdSelectionData menghasilkan input yang diperlukan untuk komponen B&A, seperti BuyerInput dan ProtectedAudienceInput, serta mengenkripsi data sebelum menyediakan hasilnya kepada pemanggil. Untuk mencegah kebocoran data di seluruh aplikasi, data ini berisi informasi dari semua pembeli yang ada di perangkat. Baca selengkapnya tentang keputusan ini di bagian pertimbangan privasi.

API ini menampilkan objek AdSelectionData:

class AdSelectionData {
  long adSelectionId // Unique identifier for the auction.
  byte[] data // Encrypted bytes containing data sourced from
              // on device custom audiences; will
              // be used as the payload to B&A.
}

Dengan menggunakan AdSelectionData, SDK di perangkat dapat mengirim permintaan ke layanan Iklan Penjual mereka dengan menyertakan data dalam permintaan POST atau PUT:

fetch('https://www.example-ssp.com/auction', {
  method: "PUT",
  body: data,
…
})

SDK di perangkat bertanggung jawab untuk mengenkode data ini. Sebaiknya gunakan solusi hemat ruang seperti mengirim permintaan ke layanan Iklan Penjual sebagai multipart/form-data.

Setelah permintaan dimulai, layanan Iklan Penjual meneruskan permintaan ke layanan SellerFrontEnd yang berjalan di TEE. Saat mengonfigurasi layanan SellerFrontEnd, penjual akan memberikan daftar alamat domain yang terkait dengan layanan BuyerFrontEnd yang dioperasikan oleh pembeli yang berpartner dengan penjual. Permintaan akan digabungkan ke berbagai layanan BuyerFrontEnd yang telah disediakan penjual, sehingga pembeli dapat membuat bid untuk kandidat iklan yang mereka pilih. Untuk pembeli tertentu, B&A hanya akan mengirim informasi tentang audiens kustom yang dimiliki pembeli sehingga tidak ada kebocoran data antar-pembeli. Setelah membuat bid, daftar iklan kandidat akan kembali ke layanan SellerFrontEnd tempat pemenang dipilih. Terakhir, layanan SellerFrontEnd menampilkan iklan pemenang yang dienkripsi ke perangkat.

Dengan respons dari permintaan ke layanan Iklan Penjual kembali di perangkat, platform menawarkan API baru kedua untuk mendekripsi hasil dan memberikan AdSelectionOutcome, objek yang sama yang ditampilkan dari lelang di perangkat saat ini.

PersistAdSelectionResultRequest {
  AdSelectionId id // Same ID returned from initial getAdSelectionData call.
  AdTechIdentifier seller // Used for enrollment checks.
  byte[] adSelectionionResult // The result of the network call to Seller Ad
                              // service/B&A.
}

persistAdSelectionResult(persistAdSelectionResultRequest);

Pelaporan

URL pelaporan akan dibuat di layanan B&A. Ping ke URL tersebut untuk melaporkan tayangan dan interaksi karena lelang masih perlu dipicu di perangkat. SDK di perangkat masih perlu memanggil reportImpression() dan reportInteraction() API menggunakan AdSelectionId yang dihasilkan dalam alur B&A. Beacon yang dihasilkan untuk pelaporan interaksi dan URL yang sesuai terdapat di dalam respons terenkripsi, sehingga selama dekripsi respons tersebut, peristiwa dan pemetaan URL disimpan di perangkat.

Pertimbangan Privasi

Proposal API Bidding & Lelang Browser di GitHub menjelaskan cara pertimbangan privasi dipertimbangkan. Proposal ini menggunakan nomenklatur Chrome, tetapi prinsip yang sama berlaku untuk Android.

adSelectionData dienkripsi untuk memastikan bahwa data dalam pengiriman hanya dapat diakses oleh PPAPI dan server tepercaya. Untuk mengurangi risiko kebocoran data karena perubahan ukuran adSelectionData, kami berencana untuk membuat adSelectionData yang sama untuk semua panggilan ke getAdSelectionData API. Ini menyiratkan bahwa semua CustomAudience di perangkat digunakan untuk membuat adSelectionData. Kami juga akan membatasi pengaruh parameter input GetAdSelectionData pada adSelectionData yang dihasilkan.

Menghasilkan adSelectionData yang sama untuk semua teknologi iklan yang menggunakan semua data lelang di perangkat akan menghasilkan payload yang lebih tinggi dan harus ditransfer dalam setiap panggilan ke server teknologi iklan, sekaligus berpotensi membuka ekosistem terhadap penyalahgunaan oleh entity berbahaya. Masalah ini dibahas di bagian Pertimbangan ukuran dan Pertimbangan anti-penyalahgunaan di bawah.

Pertimbangan ukuran

SDK klien teknologi iklan diharapkan untuk memaketkan byte terenkripsi adSelectionData ke dalam panggilan untuk iklan kontekstual yang dibuat ke server Penjual. Untuk performa yang optimal, penting untuk mengoptimalkan ukuran adSelectionData tanpa mengorbankan fungsi. Kami berencana untuk memperkenalkan pengoptimalan seperti yang disebutkan dalam Penjelasan pengoptimalan payload untuk mengurangi ukuran adSelectionData. Pengoptimalan ini akan mencakup:

  1. Menambahkan ad_render_id di CustomAudience sehingga dikirim menggunakan adSelectionData, bukan menggunakan URI dan metadata render iklan. Teknologi iklan dapat lebih mengoptimalkan hal ini dengan tidak mengirimkan data iklan di adSelectionData. Opsi ini akan didukung di CustomAudience API dalam rilis mendatang.
  2. Memastikan user_bidding_signals tidak dikirim di adSelectionData. Sebagai gantinya, teknologi iklan dapat mengambil user_bidding_signals dari server Kunci/Nilai mereka.
  3. Memungkinkan pembeli untuk memprioritaskan CustomAudience.
  4. Memungkinkan pembeli untuk menentukan prioritas penjual.
  5. Menghasilkan adSelectionData di beberapa bucket tetap untuk membatasi kebocoran bit sekaligus mengurangi ukuran payload.

Pengoptimalan ukuran akan dilakukan dengan tetap memperhatikan kekhawatiran yang timbul dalam pertimbangan privasi.

Pertimbangan anti-penyalahgunaan

Seperti disebutkan dalam pertimbangan Privasi, adSelectionData dibuat menggunakan semua data pembeli di perangkat.

Hal ini membuka ekosistem terhadap kemungkinan adanya entity berbahaya yang dapat menambahkan data pembeli palsu yang dapat menurunkan performa, payload yang membengkak hingga meningkatkan biaya, dll.

Untuk mengatasi penyalahgunaan adSelectionData, kami akan memperkenalkan tindakan berikut

  • Memungkinkan CustomAudience untuk menentukan prioritas penjual dan penjual yang disetujui secara eksplisit
  • Memungkinkan SSP untuk menentukan pembeli, prioritas pembeli, dan kuota per pembeli secara eksplisit di payload yang dihasilkan
  • Menyediakan mekanisme bagi SSP untuk menentukan jumlah maksimum pembeli per panggilan atau ukuran maksimal per pembeli.

Tindakan ini dirancang untuk memungkinkan teknologi iklan menentukan teknologi iklan lain yang berkolaborasi dengan mereka, dan untuk menetapkan batas yang dapat diterima pada payload adSelectionData yang perlu mereka proses. Kami mengusulkan memungkinkan penjual untuk menetapkan daftar dan prioritas pembeli ini dalam panggilan terpisah. Spesifikasi ini akan tetap konstan selama beberapa interval waktu untuk menghindari paparan data tambahan tentang pengguna melalui panggilan berulang.

Mitigasi yang disebutkan di atas sedang dibahas dan dapat berubah dari waktu ke waktu. Seperti yang disebutkan sebelumnya, semua mitigasi yang diperkenalkan untuk anti-penyalahgunaan dan pembatasan ukuran harus mematuhi pertimbangan privasi.