Proposal desain Bidding dan Layanan Lelang untuk Android menjelaskan detail eksekusi dan aliran data lelang yang berjalan di Android menggunakan server Bidding dan Lelang Tepercaya. Untuk memastikan data dalam pengiriman hanya ditangani oleh API yang menjaga privasi dan server tepercaya, data dienkripsi antara klien dan server menggunakan Enkripsi Kunci Publik Hybrid dua arah.
Untuk menjalankan lelang seperti yang diuraikan sebelumnya, teknologi iklan penjual di perangkat harus lakukan langkah-langkah berikut:
- Mengumpulkan dan mengenkripsi data untuk lelang server
- Mengirim permintaan ke Layanan Penjual Tidak Tepercaya
- Menerima respons dari Layanan Penjual Tidak Tepercaya
- Mendekripsi respons lelang Protected Audience dan mendapatkan hasil lelang
Protected Audience memperkenalkan dua API baru untuk mendukung lelang server yang sedang berjalan:
getAdSelectionData
API mengumpulkan data untuk lelang server dan membuat payload terenkripsi yang berisi data lelang. Server Bidding dan Lelang menggunakan payload ini untuk menjalankan lelang, membuat hasil lelang, dan menampilkan hasil lelang.- Klien teknologi iklan di perangkat dapat memanggil
persistAdSelectionResult
API untuk mendekripsi hasil yang dibuat oleh lelang server dan mendapatkan URL rendering iklan pemenang.
Teknologi iklan penjual di perangkat perlu mengintegrasikan dan membuat hal berikut untuk menjalankan lelang:
- Mengumpulkan dan mengenkripsi data untuk Penjual lelang server: Teknologi iklan harus
memanggil
getAdSelectionData
API untuk mendapatkan payload terenkripsi. - Mengirim permintaan ke Pengiriman Layanan Penjual Tidak Tepercaya: Permintaan
HTTP POST
atauPUT
berisi payload terenkripsi yang dihasilkan olehgetAdSelectionData
API ke layanan dan data penjual tidak tepercaya diperlukan oleh layanan penjual tidak tepercaya untuk membuat hasil kontekstual. - Menerima respons dari Layanan Penjual Tidak Tepercaya: Respons dari layanan penjual tidak tepercaya akan berisi hasil lelang protected audience terenkripsi dan hasil lelang kontekstual.
- Mendekripsi respons lelang protected audience dan mendapatkan hasil lelang:
Untuk mendekripsi hasil lelang protected audience, teknologi iklan penjual harus memanggil
API
persistAdSelectionResult
. Hasil yang dihasilkan olehpersistAdSelectionResult
akan membantu teknologi iklan menentukan apakah konteks iklan atau iklan audiens yang dilindungi memenangkan lelang dan URI pemenang iklan audiens yang dilindungi jika berlaku.
Fitur yang didukung untuk lelang server
Kami ingin mendukung semua fitur yang saat ini tersedia untuk lelang di perangkat. Linimasa untuk mendukung fitur ini di lelang server adalah sebagai berikut:
Lelang di Perangkat |
Lelang Server |
|||
Pratinjau Developer |
Beta |
Pratinjau Developer |
Beta |
|
Pelaporan kemenangan tingkat peristiwa |
Q1 '23 |
Q3 '23 |
T/A |
Q4 '23 |
Q1 '23 |
Q4 '23 |
T/A |
Q1 24 |
|
Q2 '23 |
Q3 '23 |
T/A |
Q4 '23 |
|
Meneruskan iklan kontekstual ke alur kerja pemilihan iklan untuk pemfilteran |
Q2 '23 |
Q1 '24 |
T/A |
T/A |
Q2 '23 |
Q3 '23 |
T/A |
Q4 '23 |
|
Q3 '23 |
Q4 '23 |
T/A |
Q4 '23 |
|
penagihan non-CPM |
Q3 '23 |
Q4 '23 |
||
Pelaporan |
Q3 '23 |
Q4 '23 |
Q3 '23 |
Q4 '23 |
Mediasi Bidding Terbuka |
T/A |
T/A |
T/A |
Q1 '24 |
Q2 '23 |
Q1 '24 |
T/A |
Q1 '24 |
|
Pengelolaan mata uang |
T/A |
T/A |
T/A |
Q1 '24 |
Integrasi K-anon |
T/A |
Q1 '24 |
T/A |
Q1 '24 |
Integrasi Agregasi Pribadi |
T/A |
T/A |
T/A |
Q3 '24 |
Menjalankan Lelang Server menggunakan Protected Audience API
Di jalur Pratinjau Developer, AdSelectionManager mengekspos dua API baru:
getAdSelectionData
dan persistAdSelectionResult
. API ini memungkinkan SDK teknologi
iklan terintegrasi dengan server Bidding dan Lelang.
Mengumpulkan dan mengenkripsi data untuk lelang server
getAdSelectionData
API menghasilkan input yang diperlukan untuk komponen Bidding dan
Lelang seperti BuyerInput
dan
ProtectedAudienceInput
, serta mengenkripsi data sebelum membuat
hasil tersedia bagi 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 dan strategi untuk
mengoptimalkannya di bagian pertimbangan ukuran.
Untuk mengakses API, akses ke Protected Audience API harus diaktifkan, dan
izin ACCESS_ADSERVICES_CUSTOM_AUDIENCE
harus ditentukan di
manifes pemanggil.
public class AdSelectionManager {
public void getAdSelectionData(
GetAdSelectionDataRequest getAdSelectionDataRequest,
Executor executor,
OutcomeReceiver<GetAdSelectionDataOutcome, Exception> receiver) {}
}
GetAdSelectionDataRequest
- Pemanggil harus menetapkan kolom
seller
dalam permintaan karena digunakan untuk menjalankan pemeriksaan pendaftaran sebelum melayani permintaan. - Kolom
coordinatorOriginUri
bersifat opsional.- Jika disetel, ini harus sama dengan skema, nama host, dan porta URL koordinator yang dikonfigurasi saat men-deploy server B&A penjual.
- Koordinator harus termasuk dalam daftar koordinator yang disetujui:
Penyedia URI Asal URI Default Google Cloud https://publickeyservice.pa.gcp.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.gcp.privacysandboxservices.com Ya Amazon Web Services https://publickeyservice.pa.aws.privacysandboxservices.com/.well-known/protected-auction/v1/public-keys https://publickeyservice.pa.aws.privacysandboxservices.com Tidak - Jika asal koordinator tidak diberikan, koordinator default akan digunakan.
- Meskipun kecil kemungkinan URL Koordinator akan berubah, sangat disarankan untuk menerapkan mekanisme untuk mengelola URL ini secara dinamis. Hal ini memastikan bahwa setiap perubahan berikutnya pada URL dapat diakomodasi tanpa memerlukan rilis SDK baru.
public class GetAdSelectionDataRequest {
public setSeller(AdTechIdentifier seller);
public setCoordinatorOriginUri(Uri coordinatorOriginUri)
}
Setelah permintaan divalidasi, data pembeli di perangkat disusun menjadi
BuyerInput
dan ProtectedAudienceInput
. Objek payload akhir kemudian
dienkripsi menggunakan Enkripsi Kunci Publik Hybrid dua arah.
GetAdSelectionDataOutcome
GetAdSelectionDataOutcome
dibuat sebagai hasil dari getAdSelectionData
API. Isinya adalah sebagai berikut:
adSelectionId
: bilangan bulat buram untuk mengidentifikasi pemanggilangetAdSelectionData
ini. Klien teknologi iklan harus mempertahankan nilaiadSelectionId
ini karena bertindak sebagai pointer ke panggilangetAdSelectionData
. ID ini diperlukan olehpersistAdSelectionResult
API untuk mendekripsi hasil lelang dari server Bidding dan Lelang serta diperlukan oleh APIreportImpression
danreportEvent
.adSelectionData
: Ini adalah data lelang terenkripsi yang akan diperlukan oleh server Bidding dan Lelang untuk menjalankan lelang. Metode ini berisi:- Data Audiens Kustom yang difilter didasarkan pembatasan frekuensi, filter penginstalan aplikasi, dan persyaratan lelang server untuk Audiens Kustom.
- Pada versi mendatang, versi ini akan berisi data penginstalan aplikasi.
public class GetAdSelectionDataOutcome {
Public getAdSelectionId(long adSelectionId);
public byte[] getAdSelectionData();
}
Penanganan error, pengecualian, dan kegagalan
Jika pembuatan data pemilihan iklan tidak berhasil diselesaikan karena
alasan seperti argumen tidak valid, waktu tunggu habis, atau konsumsi resource berlebih,
callback OutcomeReceiver.onError()
akan memberikan AdServicesException
dengan
perilaku berikut:
- Jika
getAdSelectionData
dimulai dengan argumen yang tidak valid,AdServicesException
` akan menunjukkan IllegalArgumentException sebagai penyebabnya. - Semua error lainnya akan menerima
AdServicesException
denganIllegalStateException
sebagai penyebabnya.
Mengirim permintaan ke layanan penjual tidak tepercaya
Dengan AdSelectionData
, SDK di perangkat dapat mengirim permintaan ke layanan iklan
penjualnya 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 yang hemat ruang seperti mengirim permintaan ke layanan iklan penjual sebagai multibagian/formulir data.
Menerima respons dari layanan penjual tidak tepercaya
Seperti yang dijelaskan dalam Penjelasan Server Bidding dan Lelang, saat layanan penjual tidak tepercaya menerima permintaan, layanan akan melakukan panggilan ke pembeli partner untuk iklan kontekstual.
Layanan penjual tidak tepercaya meneruskan adSelectionData
dan
AuctionConfig
yang dienkripsi ke layanan SellerFrontEnd server Bidding dan Lelang
yang berjalan dalam TEE.
Saat lelang Protected Audience selesai, layanan SellerFrontEnd mengenkripsi hasil lelang dan menampilkannya sebagai respons terhadap layanan penjual tidak tepercaya.
Layanan penjual tidak tepercaya mengirimkan respons ke perangkat yang berisi iklan kontekstual dan/atau hasil lelang Protected Audience terenkripsi.
Saat menerima respons, kode teknologi iklan penjual di perangkat dapat memilih untuk
hanya menggunakan iklan kontekstual dalam respons atau jika dianggap ada
nilai inkremental dalam mendapatkan hasil Protected Audience, kode tersebut dapat memilih untuk
mendekripsi hasil Protected Audience dengan memanggil PersistAdSelectionResult
API.
PersistAdSelectionResult API
Untuk mendekripsi hasil Protected Audience, teknologi iklan penjual dapat memanggil
Protected Audience API persistAdSelectionResult
kedua. API mendekripsi hasil
dan menampilkan AdSelectionOutcome
, objek yang sama seperti yang ditampilkan dari
lelang di perangkat saat ini.
Untuk mengakses API, pemanggil harus mengaktifkan akses ke Protected Audience API dan
menentukan izin ACCESS_ADSERVICES_CUSTOM_AUDIENCE
di manifesnya.
public void persistAdSelectionResult(
PersistAdSelectionResultRequest persistAdSelectionResultRequest,
Executor executor,
OutcomeReceiver<AdSelectionOutcome, Exception> receiver) {}
PersistAdSelectionResultRequest
Pemanggil harus menetapkan hal berikut dalam permintaan:
public final class PersistAdSelectionResultRequest {
Public setAdSelectionId(long adSelectionId);
public setSeller(AdTechIdentifier seller);
public setAdSelectionResult(byte[] adSelectionResult);
}
adSelectionId
: ID buram yang dihasilkan oleh panggilangetAdSelectionData
yang hasilnya ingin didekripsi oleh pemanggil.seller
: ID teknologi iklan penjual harus ditetapkan dalam permintaan untuk menjalankan pemeriksaan pendaftaran sebelum melayani permintaan.adSelectionResult
: Hasil lelang terenkripsi yang dihasilkan oleh server Bidding dan Lelang yang ingin didekripsi oleh pemanggil.
Respons AdSelectionOutcome
Jika ada pemenang Protected Audience, AdSelectionOutcome
akan menampilkan
URI rendering iklan pemenang. Setelah adSelectionResult
didekripsi, data pelaporan
akan disimpan secara internal. Callback OutcomeReceiver.onResult()
menampilkan
AdSelectionOutcome
yang berisi:
URI
: Jika ada iklan Protected Audience yang menang, URL rendering iklan untuk iklan pemenang akan ditampilkan. Jika tidak ada pemenang Protected Audience, `Uri.EMPTY akan ditampilkan.adSelectionId
:adSelectionId
yang terkait dengan berjalannya lelang server ini.
Penanganan error, pengecualian, dan kegagalan
Jika pembuatan data pemilihan iklan tidak berhasil diselesaikan karena
alasan seperti argumen tidak valid, waktu tunggu habis, atau konsumsi resource berlebih,
callback OutcomeReceiver.onError()
akan memberikan AdServicesException
dengan
perilaku berikut:
- Jika
getAdSelectionData
dimulai dengan argumen yang tidak valid,AdServicesException
akan menunjukkanIllegalArgumentException
sebagai penyebabnya. - Semua error lainnya akan menerima
AdServicesException
denganIllegalStateException
sebagai penyebabnya.
Pertimbangan Privasi
adSelectionData
dienkripsi untuk memastikan bahwa data dalam pengiriman hanya dapat diakses
oleh PPAPI dan server tepercaya.
Meskipun ada enkripsi, kebocoran data dapat terjadi karena ukuran adSelectionData
. Ukuran
adSelectionData
dapat bervariasi karena:
- Perubahan pada data
CustomAudience
ada di perangkat. - Perubahan pada logika pemfilteran
CustomAudience
. - Perubahan pada input untuk panggilan
getAdSelectionData
.
Perubahan ukuran adSelectionData
dapat digunakan untuk membuat ID lintas-aplikasi
seperti yang disebutkan dalam diskusi kebocoran 1-bit. Banyak
mitigasi yang berlaku untuk kebocoran 1-bit juga berlaku di sini.
Untuk mengelola kebocoran ini, kami berencana membuat adSelectionData
yang sama untuk semua
panggilan ke getAdSelectionData
API. Dalam rilis awal, semua
CustomAudiences
di perangkat digunakan untuk membuat adSelectionData
dan
payload terenkripsi akan ditambahkan ke variasi ukuran mask. Kami juga akan membatasi
pengaruh parameter input GetAdSelectionData
pada adSelectionData
yang dihasilkan.
Namun, membuat adSelectionData
yang sama untuk semua teknologi iklan yang menggunakan semua
data lelang di perangkat menghasilkan payload besar yang sekarang perlu ditransfer
dalam setiap panggilan ke server teknologi iklan. Penggunaan semua audiens kustom di perangkat untuk
membuat payload lelang juga akan membuka ekosistem untuk penyalahgunaan dari entitas
berbahaya. Kita telah membahas masalah ini di bagian Pengoptimalan ukuran dan
Mitigasi penyalahgunaan di bawah.
Pengoptimalan ukuran
SDK klien teknologi iklan diharapkan untuk memaketkan byte terenkripsi
adSelectionData
ke dalam panggilan kontekstual HTTP PUT/POST
yang dilakukan ke server
teknologi iklan. Untuk latensi dan biaya waktu round-trip yang lebih rendah, Anda perlu mengurangi
ukuran adSelectionData
sebanyak mungkin tanpa memengaruhi utilitas.
Kami berencana untuk mengeksplorasi dan berpotensi memperkenalkan pengoptimalan berikut dalam
rilis mendatang untuk mengurangi ukuran adSelectionData
:
Payload yang dihasilkan dalam set ukuran bucket tetap dengan padding: Untuk meminimalkan kebocoran dari variasi ukuran sekaligus tetap memungkinkan payload yang lebih rendah, sebaiknya gunakan bucket ukuran tetap untuk payload yang dihasilkan. Dengan mempertahankan jumlah bucket yang kecil, misalnya 7, jumlah entropi yang bocor per panggilan ke
getAdSelectionData
kurang dari 3 bit.Jika data di perangkat melebihi ukuran bucket maksimum, strategi yang disebutkan di bawah seperti nilai prioritas akan digunakan untuk memutuskan data mana yang dihapus.
Konfigurasi Pembeli: Kami sedang menilai kelayakan untuk mengizinkan pembeli menyiapkan konfigurasi payload per pembeli. Konfigurasi ini akan berguna untuk mengidentifikasi lelang mana yang ingin diikuti oleh pembeli. Jika memungkinkan, selama pendaftaran, teknologi iklan pembeli dapat mendaftarkan endpoint tempat Protected Audience akan mengambil konfigurasi payload dengan ritme reguler harian. Atau, API yang menjaga privasi akan mengekspos API untuk memungkinkan teknologi iklan pembeli mendaftarkan endpoint ini.
Konfigurasi ini kemudian akan digunakan untuk menilai kontribusi pembeli pada
adSelectionData
yang dihasilkan untuk setiap permintaangetAdSelectionData
.Konfigurasi payload pembeli akan memungkinkan pembeli untuk menentukan:
- Daftar penjual yang diizinkan: CustomAudiences Pembeli akan ditambahkan ke
payload hanya jika panggilan
getAdSelectionData
dimulai oleh penjual dalam daftar yang diizinkan. Kami akan mengambil konfigurasi payload pada ritme harian agar daftar yang diizinkan terus diperbarui. - Batas ukuran per penjual: Pembeli dapat menetapkan batas ukuran per penjual untuk menentukan ukuran data yang akan dikirim dalam payload saat lelang dimulai oleh penjual tertentu. Hal ini akan berguna jika pembeli ingin menyediakan lebih banyak resource untuk memproses data lelang dari penjual tertentu. SellerFrontendService hanya meneruskan data khusus pembeli ke setiap BuyerFrontendService. Jadi, dengan menentukan batas ukuran per penjual, pembeli dapat secara eksplisit mengontrol jumlah data yang diserap dan diproses oleh BuyerFrontendService server Lelang dan Pembeli untuk lelang yang dijalankan oleh penjual.
- Daftar penjual yang diizinkan: CustomAudiences Pembeli akan ditambahkan ke
payload hanya jika panggilan
Konfigurasi Penjual: Kami menilai kelayakan konfigurasi lelang per penjual yang memungkinkan penjual menentukan parameter lelang untuk mengontrol ukuran payload dan peserta lelang. Jika memungkinkan, selama pendaftaran, teknologi iklan penjual dapat menentukan endpoint tempat Protected Audience dapat mengambil konfigurasi lelang per penjual dengan ritme reguler. Selanjutnya, konfigurasi ini akan digunakan untuk menentukan komposisi dan batas
adSelectionData
yang dihasilkan untuk setiap permintaangetAdSelectionData
.Serupa dengan konfigurasi pembeli, konfigurasi per penjual akan memungkinkan penjual menentukan kumpulan pembeli mana yang akan dilihat di lelang dan menentukan batas kontribusi per pembeli terhadap ukuran payload.
Konfigurasi lelang penjual akan memungkinkan penjual untuk menentukan:
- Daftar pembeli yang diizinkan: Untuk lelang yang dimulai oleh penjual tertentu, hanya pembeli dalam daftar yang diizinkan yang dapat memberikan kontribusi CustomAudiences untuk lelang. Konfigurasi lelang harus diperbarui setiap hari agar daftar yang diizinkan tetap diperbarui dengan daftar pembeli sisi server yang diizinkan.
- Batas ukuran per pembeli: Penjual dapat menentukan batas per pembeli untuk mengatur ukuran data yang diupload oleh setiap pembeli ke dalam payload yang dikirim ke SellerFrontendService. Jika pembeli melebihi batas ukuran per pembeli, prioritas CustomAudience yang ditetapkan dalam konfigurasi payload pembeli akan digunakan untuk mendapatkan data dalam batas yang diharapkan.
- Prioritas per pembeli: Mengizinkan penjual menetapkan prioritas per pembeli. Prioritas pembeli akan digunakan untuk mengidentifikasi data pembeli mana yang harus disimpan dalam payload jika ukuran payload melebihi batas ukuran payload.
- Batas ukuran maksimum untuk payload: Penjual yang berbeda mungkin memiliki alokasi resource yang berbeda dan mungkin ingin menetapkan batas ukuran maksimum untuk payload lelang per permintaan. Batas ukuran maksimum akan mengikuti bucket ukuran tetap yang ditetapkan oleh Protected Audience API.
Perubahan Audiens Kustom
- Menentukan prioritas Audiens Kustom: Izinkan pembeli menentukan nilai prioritas
dalam Audiens Kustom. Kolom
priority
akan digunakan untuk mengidentifikasi audiens kustom yang harus disertakan dalam lelang jika kumpulan audiens kustom pembeli melebihi batas ukuran per penjual atau per pembeli. Nilai prioritas yang tidak ditentukan dalam Audiens Kustom akan ditetapkan secara default ke0.0
.
- Menentukan prioritas Audiens Kustom: Izinkan pembeli menentukan nilai prioritas
dalam Audiens Kustom. Kolom
Perubahan Data Payload
- Kurangi data yang dikirim dalam payload: Seperti yang dijelaskan dalam Pengoptimalan payload layanan
Bidding dan Lelang, payload yang lebih tinggi didorong oleh
data
ads
audiens kustom, sinyal bidding pengguna, sinyal Android. Payload yang lebih tinggi dapat diturunkan dengan:- Meminta klien mengirim ID render iklan (bukan objek iklan) dalam payload.
- Meminta klien untuk tidak mengirimkan data iklan dalam payload.
- Tidak mengirim sinyal bidding pengguna dalam payload klien.
- Kurangi data yang dikirim dalam payload: Seperti yang dijelaskan dalam Pengoptimalan payload layanan
Bidding dan Lelang, payload yang lebih tinggi didorong oleh
data
Meskipun strategi yang disebutkan di atas memungkinkan teknologi iklan untuk menentukan konfigurasi guna
mengelola komposisi dan batas payload adSelectionData
, strategi tersebut juga dapat menjadi
faktor untuk memodulasi ukuran adSelectionData
dengan mengubah parameter
konfigurasi. Untuk menghindarinya, konfigurasi akan diambil setiap hari oleh Protected
Audience dari endpoint yang dikonfigurasi.
Pengoptimalan latensi
Agar lelang server memiliki tingkat utilitas yang diinginkan, kita perlu memastikan bahwa
getAdSelectionData
API dan persistAdSelectionResult
API memiliki latensi rendah per
panggilan. Meskipun kami berencana memberikan dukungan fitur untuk API pada tahun 2023, rilis
berikutnya akan berfokus pada tolok ukur latensi dan pengoptimalan untuk API.
Kami sedang mempelajari strategi berikut untuk menjaga latensi dalam batas yang dapat diterima:
Pra-pembuatan data Protected Audience per penjual: Karena konfigurasi lelang penjual dan konfigurasi payload pembeli akan stabil selama durasi yang cukup lama (harian), platform dapat melakukan pra-komputasi dan menyimpan data Protected Audience yang memenuhi syarat.
Tindakan ini akan mengharuskan platform membuat mekanisme untuk memantau pembaruan audiens kustom dan mengubah data Protected Audience yang dihasilkan sebelumnya berdasarkan pembaruan tersebut. Platform ini juga perlu mendeklarasikan SLO pada perlombaan penundaan yang bisa diharapkan teknologi iklan antara pembaruan audiens kustom dan perubahan di
adSelectionData
` yang dibuat untuk lelang server.Karena perangkat menyediakan model komputasi resource terbatas dengan prioritas proses yang bervariasi, kami menyadari bahwa penyediaan fasilitas pra-pembuatan ini harus disertai dengan keandalan dan jaminan SLO yang tinggi.
Pra-pembuatan data Protected Audience akan didasarkan pada
- Keikutsertaan penjual untuk pra-pembuatan data Protected Audience.
- Pembeli yang memenuhi syarat untuk berpartisipasi dalam lelang yang dimulai oleh penjual tertentu.
- Mengidentifikasi audiens kustom per pembeli yang akan menjadi bagian dari
payload berdasarkan:
- Batas ukuran per pembeli, prioritas per pembeli, dan batas ukuran maksimum yang ditentukan dalam konfigurasi penjual,
- Batas ukuran per penjual, prioritas audiens kustom yang ditentukan dalam konfigurasi pembeli.
Penerapan pemfilteran negatif yang lebih menarik: Jika dipilih oleh penjual, platform dapat menghitung
adSelectionData
terlebih dahulu dengan melakukan pra-pembuatan data Protected Audience dan menerapkan pemfilteran negatif dari data panggilangetAdSelectionData
. Dengan demikian, penjual dapat menyeimbangkan pengurangan latensi sekaligus menerima penghentian pemfilteran negatif.Platform ini dapat memberikan dukungan ini dengan memberikan opsi default dalam Konfigurasi penjual dengan batas penghentian dan opsi penggantian di
getAdSelectionData
untuk memungkinkan komputasi terbaru jika diperlukan. Atau, platform dapat memberikan API inisialisasi tambahan yang akan dipanggil sebelumgetAdSelectionData
untuk menyiapkan lelang.Komputasi payload untuk beberapa lelang: Dalam skenario tertentu, mungkin sebaiknya gunakan API yang memiliki performa latensi baik dengan mengorbankan peningkatan penghentian data. Untuk menyediakan hal ini, platform dapat memperkenalkan API inisialisasi untuk melakukan komputasi seluruh payload dan memberikan referensi ke payload yang dikomputasi ke pemanggil.
Untuk panggilan berikutnya ke
getAdSelectionData
, pemanggil dapat memberikan referensi ke payload yang telah dikomputasi sebelumnya yang akan digunakan untuk pembuatanadSelectionData
.
Ketiga strategi yang disebutkan di atas berada pada tahap eksplorasi awal dan dimaksudkan untuk mendeskripsikan arah yang mungkin diambil platform tersebut untuk mengoptimalkan latensi. Selagi terus mempelajari profil latensi API dan persyaratan teknologi iklan yang lebih mendetail, kami akan terus mengusulkan strategi tambahan.
Mitigasi dan identifikasi penyalahgunaan
Seperti disebutkan dalam pertimbangan Privasi, adSelectionData
dibuat menggunakan
semua data pembeli di perangkat.
Namun, jika semua data pembeli pada perangkat digunakan untuk membuat
output adSelectionData
, maka entitas berbahaya dapat berpura-pura sebagai pembeli dan
membuat data pembeli yang menipu untuk menurunkan performa Android, menggelembungkan payload hingga
menaikkan biaya teknologi iklan untuk menjalankan lelang atau bidding, dan sebagainya.
Mitigasi
Beberapa tindakan yang disebutkan di bagian pertimbangan ukuran seperti konfigurasi payload pembeli yang berisi daftar penjual yang diizinkan dan konfigurasi lelang penjual yang berisi pembeli yang diizinkan akan membantu mengecualikan data yang tidak terduga dalam payload.
Tindakan pertimbangan ukuran lain seperti mengizinkan SSP menentukan prioritas pembeli, menempatkan kuota per pembeli di payload yang dihasilkan, dan menetapkan ukuran maksimum per payload lelang juga dapat membantu mengurangi dampak penggelembungan payload yang berbahaya. Tindakan ini dimaksudkan untuk memungkinkan teknologi iklan menentukan teknologi iklan lain yang berkolaborasi dengannya, serta untuk menetapkan batas yang dapat diterima pada payload yang perlu diproses.
Seperti yang disebutkan sebelumnya, semua mitigasi yang diperkenalkan untuk anti-penyalahgunaan dan pembatasan ukuran harus mematuhi pertimbangan privasi.
Identifikasi entitas berbahaya
Meskipun mitigasi yang disebutkan di atas melindungi pembuatan adSelectionData
untuk
lelang server, mitigasi tidak membantu mengidentifikasi entitas berbahaya atau melindungi
platform dari penyalahgunaan seperti pembuatan jumlah audiens kustom yang belum pernah ada
sebelumnya dari pembeli.
Untuk memastikan stabilitas dan kesehatan platform, kami perlu menemukan mekanisme untuk mengidentifikasi entitas berbahaya, mengidentifikasi vektor penyalahgunaan, dan mengidentifikasi motivasi untuk serangan tertentu. Dalam rilis selanjutnya, kami akan memperkenalkan penjelasan yang memberikan detail potensi vektor dan perlindungan terhadap penyalahgunaan untuk melawannya.