Update terbaru
- Menambahkan informasi tentang menjadwalkan pembaruan audiens kustom
- Menambahkan integrasi Pelaporan Atribusi dengan Protected Audience
- Memublikasikan linimasa fitur Protected Audience.
- FLEDGE telah diganti namanya menjadi Protected Audience API.
- Menambahkan proposal untuk delegasi audiens kustom.
- Menghapus persyaratan k-anonymity untuk URL update harian.
Protected Audience masih dalam versi Beta dan tersedia untuk diuji di perangkat publik.
Dengan Protected Audience, Anda dapat:
- Mengelola audiens kustom berdasarkan tindakan pengguna sebelumnya.
- Memulai lelang di perangkat dengan dukungan penjual tunggal atau mediasi waterfall.
- Melatih pelaporan tayangan setelah pemilihan iklan.
Untuk memulai, baca Panduan developer Protected Audience. Kami mengharapkan masukan Anda seiring upaya kami untuk terus mengembangkan Protected Audience.
Linimasa
Kami akan merilis fitur baru dalam beberapa bulan mendatang. Tanggal rilis pasti akan bervariasi tergantung fitur, dan tabel ini akan diperbarui dengan link ke dokumentasi saat tersedia.
Fitur | Tersedia di Pratinjau Developer | Tersedia dalam versi Beta |
---|---|---|
Pelaporan tingkat peristiwa | Q1 '23 | Q3 '23 |
Mediasi waterfall | Q1 '23 | Q4 '23 |
Pemfilteran iklan instal aplikasi | Q2 '23 | Q3 '23 |
Pemfilteran pembatasan frekuensi | Q2 '23 | Q3 '23 |
Meneruskan iklan kontekstual ke alur kerja pemilihan iklan untuk pemfilteran | Q2 '23 | Q3 '23 |
Pelaporan interaksi | Q2 '23 | Q3 '23 |
Bergabung ke delegasi audiens kustom | Q3 '23 | Q4 '23 |
Penagihan non-CPM | Q3 '23 | Q4 '23 |
Integrasi layanan Bidding dan Lelang | Q3 '23 | Q4 '23 |
Pelaporan debug | Q3 '23 | Q4 '23 |
Integrasi Pelaporan Atribusi | T/A | Q4 '23 |
Mediasi bidding terbuka | Q4 '23 | Q4 '23 |
Pengelolaan mata uang | Q1 '24 | Q2 '24 |
Integrasi K-anon | T/A | Q2 '24 |
Integrasi pelaporan gabungan | Q3 '24 | Q4 '24 |
Ringkasan
Dalam periklanan seluler, pengiklan biasanya harus menayangkan iklan kepada pengguna yang mungkin akan tertarik berdasarkan cara mereka berinteraksi sebelumnya dengan aplikasi pengiklan. Misalnya, developer SportingGoodsApp sebaiknya beriklan kepada pengguna yang memiliki item tersisa di keranjang belanjanya dengan menampilkan iklan untuk mengingatkan pengguna agar menyelesaikan pembelian. Dalam industri ini, biasanya ide umum ini dijelaskan dengan istilah seperti "pemasaran ulang" dan "penargetan audiens kustom".
Saat ini, kasus penggunaan tersebut biasanya diterapkan dengan membagikan informasi kontekstual tentang cara iklan ditampilkan (seperti nama aplikasi) dan informasi pribadi seperti daftar audiens kepada platform teknologi iklan. Dengan menggunakan informasi ini, pengiklan dapat memilih iklan yang relevan di server mereka.
Protected Audience API di Android (sebelumnya disebut FLEDGE) mencakup API berikut untuk platform teknologi iklan dan pengiklan guna mendukung kasus penggunaan berbasis interaksi umum dengan cara yang membatasi pembagian kedua ID tersebut di berbagai aplikasi dan informasi interaksi aplikasi pengguna dengan pihak ketiga:
- Custom Audience API: Berfokus pada abstraksi "audiens kustom", yang mewakili audiens yang ditunjuk pengiklan dengan niat umum. Informasi audiens disimpan di perangkat dan dapat dikaitkan dengan iklan kandidat yang relevan untuk audiens dan metadata arbitrer, seperti sinyal bidding. Informasi tersebut dapat digunakan sebagai dasar untuk bid pengiklan, pemfilteran iklan, dan rendering.
- Ad Selection API: Fitur ini menyediakan framework yang menyusun alur kerja platform teknologi iklan yang memanfaatkan sinyal di perangkat untuk menentukan iklan "pemenang" dengan mempertimbangkan iklan kandidat yang disimpan secara lokal, dan melakukan pemrosesan tambahan pada iklan kandidat yang ditampilkan ke perangkat oleh platform teknologi iklan.
Pada tingkat tinggi, integrasi berfungsi sebagai berikut:
SportingGoodsApp ingin mengingatkan penggunanya untuk membeli item merchandise yang tersisa di keranjang mereka jika mereka belum menyelesaikan pembelian dalam waktu 2 hari. SportingGoodsApp menggunakan Custom Audience API untuk menambahkan pengguna ke daftar audiens "produk dalam keranjang". Platform ini mengelola dan menyimpan daftar audiens tersebut di perangkat, sehingga membatasi pembagian dengan pihak ketiga. SportingGoodsApp berpartner dengan platform teknologi iklan untuk menampilkan iklannya kepada pengguna di daftar audiensnya. Platform teknologi iklan mengelola metadata untuk daftar audiens dan menyediakan iklan kandidat, yang akan disediakan untuk alur kerja pemilihan iklan sebagai pertimbangan. Platform ini dapat dikonfigurasi untuk secara berkala mengambil iklan berbasis audiens yang diperbarui di latar belakang. Tindakan ini membantu menjaga daftar iklan kandidat berbasis audiens tetap baru dan tidak berkorelasi dengan permintaan yang dikirim ke server iklan pihak ketiga selama peluang iklan (yaitu permintaan iklan kontekstual).
Ketika pengguna bermain FrisbeeGame di perangkat yang sama, mereka mungkin melihat iklan yang mengingatkan mereka untuk menyelesaikan pembelian item yang tersisa di keranjang belanja SportingGoodsApp. Hal ini dapat dilakukan oleh FrisbeeGame (dengan SDK iklan terintegrasi) yang memanggil Ad Selection API untuk memilih iklan pemenang bagi pengguna berdasarkan daftar audiens mana pun yang mungkin memuat mereka (dalam contoh ini, audiens kustom "produk dalam keranjang" yang dibuat oleh SportingGoodsApp). Alur kerja pemilihan iklan dapat disiapkan untuk mempertimbangkan iklan yang diambil dari server platform teknologi iklan, selain iklan di perangkat yang terkait dengan audiens kustom serta sinyal di perangkat lainnya. Alur kerja juga dapat disesuaikan oleh platform teknologi iklan dan SDK iklan dengan logika penskoran dan bidding kustom untuk mencapai sasaran iklan yang tepat. Pendekatan ini memungkinkan data minat atau interaksi aplikasi pengguna untuk menjadi dasar pemilihan iklan, sekaligus membatasi pembagian data ini dengan pihak ketiga.
SDK platform teknologi iklan atau aplikasi penayangan iklan merender iklan yang dipilih.
Platform ini memfasilitasi pelaporan tayangan dan hasil pemilihan iklan. Kemampuan pelaporan ini adalah pelengkap untuk Attribution Reporting API. Platform teknologi iklan dapat melakukan penyesuaian berdasarkan kebutuhan pelaporannya.
Mendapatkan akses ke Protected Audience di API Android
Platform teknologi iklan harus mendaftar agar dapat mengakses Protected Audience API. Lihat Mendaftar ke akun Privacy Sandbox untuk mengetahui informasi selengkapnya.
Pengelolaan audiens kustom
Audiens kustom
Audiens kustom mewakili sekelompok pengguna yang ditentukan oleh pengiklan dengan niat atau minat yang sama. Aplikasi atau SDK dapat menggunakan audiens kustom untuk menunjukkan audiens tertentu, misalnya seseorang yang memiliki "item tersisa di keranjang belanjanya" atau "menyelesaikan level pemula" sebuah game. Platform ini menjaga dan menyimpan informasi audiens secara lokal di perangkat dan tidak mengekspos audiens kustom tempat pengguna berada. Audiens kustom berbeda dengan grup minat Protected Audience Chrome, dan tidak dapat dibagikan di seluruh web dan aplikasi. Hal ini membantu membatasi pembagian informasi pengguna.
Aplikasi pengiklan atau SDK terintegrasi dapat bergabung atau meninggalkan audiens kustom berdasarkan, misalnya, interaksi pengguna di aplikasi.
Metadata audiens kustom
Setiap audiens kustom berisi metadata berikut:
- Pemilik: Nama paket aplikasi pemilik. Secara implisit, nama ini ditetapkan ke nama paket aplikasi pemanggil.
- Pembeli: Jaringan iklan pembeli yang mengelola iklan untuk audiens kustom tersebut. Pembeli juga mewakili pihak yang dapat mengakses audiens kustom dan mengambil informasi iklan yang relevan. Pembeli ditentukan dengan mengikuti format eTLD+1.
- Nama: Nama atau ID arbitrer untuk audiens kustom, misalnya pengguna yang memiliki "pengabai keranjang belanja". Atribut ini dapat digunakan sebagai, misalnya, salah satu kriteria penargetan dalam kampanye iklan pengiklan, atau string kueri di URL untuk mengambil kode bidding.
- Waktu aktivasi dan waktu habis masa berlaku: Kolom ini menentukan jangka waktu ketika audiens kustom tersebut akan berlaku. Platform ini menggunakan informasi ini untuk menarik keanggotaan dari audiens kustom. Waktu habis masa berlaku tidak boleh melebihi periode durasi maksimum untuk membatasi masa pakai audiens kustom.
- URL update harian: URL yang digunakan platform untuk mengambil iklan kandidat dan metadata lainnya yang ditentukan dalam kolom "Sinyal bidding pengguna" dan "Sinyal bidding tepercaya" secara berulang. Untuk detail selengkapnya, lihat bagian cara mengambil iklan kandidat untuk audiens kustom.
- Sinyal bidding pengguna: Sinyal khusus platform teknologi iklan untuk setiap bidding iklan pemasaran ulang. Contoh sinyal mencakup: lokasi kasar pengguna, lokalitas yang dipilih, dan sebagainya.
- Data bidding tepercaya: Platform teknologi iklan mengandalkan data real time sebagai dasar untuk pengambilan dan penskoran Iklan. Misalnya, Iklan mungkin kehabisan anggaran dan harus segera dihentikan penayangannya. Teknologi iklan dapat menentukan endpoint URL tempat data real-time dapat diambil dan pencarian real-time perlu dilakukan untuk menemukan kumpulan kunci. Server yang menangani permintaan ini akan menjadi server tepercaya yang dikelola oleh platform teknologi iklan.
- URL logika bidding: URL yang digunakan platform untuk mengambil kode bidding dari platform sisi permintaan. Platform melakukan langkah ini ketika lelang iklan dimulai.
- Iklan: Daftar iklan kandidat untuk audiens kustom. Daftar iklan ini mencakup metadata iklan khusus platform teknologi iklan dan URL untuk merender iklan. Saat lelang dimulai untuk audiens kustom, daftar metadata iklan ini akan dipertimbangkan. Daftar iklan ini akan diperbarui menggunakan endpoint URL update harian jika memungkinkan. Karena keterbatasan resource pada perangkat seluler, ada batasan jumlah iklan yang dapat disimpan dalam audiens kustom.
Delegasi audiens kustom
Definisi dan konfigurasi audiens kustom tradisional biasanya mengandalkan teknologi dan integrasi sisi server yang didorong oleh teknologi iklan melalui kemitraan dengan klien dan partner agensi dan pengiklan. Protected Audience API memungkinkan definisi dan konfigurasi audiens kustom sekaligus melindungi privasi pengguna. Untuk bergabung dengan audiens kustom, teknologi iklan 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 Audience API bertujuan untuk mendukung SDK ini dengan memberikan solusi fleksibel untuk pengelolaan audiens kustom dengan memungkinkan pemanggil di perangkat memanggil pembuatan audiens kustom atas nama pembeli. Proses ini disebut delegasi audiens kustom. Konfigurasikan delegasi audiens kustom dengan mengikuti langkah-langkah berikut:
Bergabung dengan audiens kustom
Ada dua cara untuk bergabung dengan audiens kustom:
joinCustomAudience()
Aplikasi atau SDK dapat meminta untuk bergabung dengan audiens kustom dengan memanggil
joinCustomAudience()
setelah membuat instance objek CustomAudience
dengan
parameter yang diharapkan. Berikut adalah contoh cuplikan kode ilustratif:
CustomAudience audience = new CustomAudience(
Buyer = "example-dsp.com",
Name = "running-shoes",
ActivationTime = now(),
ExpirationTime = ActivationTime.plus(30 days),
DailyUpdateURL = Uri.parse("https://..."),
UserBiddingSignals = new JSONObject("{...}"),
TrustedBiddingURL = Uri.parse("https://..."),
TrustedBiddingKeys = {'key1","key2", ...,"key n"},
BiddingLogicURL = Uri.parse("https://..."),
Ads = [new AdData(renderUrl = Uri.parse("https://..."),
metadata = new JSONObject("{...}"), ...];
// Invoke ad services API to join a custom audience.
joinCustomAudience(audience);
fetchAndJoinCustomAudience()
Aplikasi atau SDK dapat meminta untuk bergabung dengan audiens kustom atas nama teknologi iklan yang
tidak memiliki kehadiran di perangkat dengan memanggil fetchAndJoinCustomAudience()
dengan
parameter yang diharapkan, seperti dalam contoh berikut:
FetchAndJoinCustomAudienceRequest fetchRequest = new FetchAndJoinCustomAudienceRequest(
// Example: Optional verification token passed inside the fetch URL
FetchURI = Uri.parse("https://example-dsp.com/...?mytoken=arbitrary1234"),
// All the following parameters are optional
Name = "running-shoes",
ActivationTime = now(),
ExpirationTime = ActivationTime.plus(30 days),
UserBiddingSignals = new JSONObject("{...}")
);
fetchAndJoinCustomAudience(fetchRequest);
Endpoint URL, yang dimiliki oleh pembeli, akan merespons kembali dengan objek JSON
CustomAudience
dalam isi respons. Kolom pembeli dan pemilik audiens kustom
diabaikan (dan diisi otomatis oleh API). API juga menerapkan bahwa URL
update harian juga akan cocok dengan eTLD+1 pembeli.
{
"name": "running-shoes",
"activation_time": 1680603133000,
"expiration_time": 1680803133000,
"user_bidding_signals" : {"signal1": "value"},
"trusted_bidding_data": {
"trusted_bidding_uri": "https://example-dsp.com/.."
"trusted_bidding_keys": ["k1", "k2"],
},
"bidding_logic_uri": "https://example-dsp.com/...",
"daily_update_uri": "https://example-dsp.com/...",
"ads": [
{
"render_uri": "https://example-dsp.com/...",
"metadata": {},
"ad_filters": {
"frequency_cap": {
"win": [
{
"ad_counter_key": 1,
"max_count": 2,
"interval_in_seconds": 60
},
],
"view": [
{
"ad_counter_key": 2,
"max_count": 10,
"interval_in_seconds": 3600
},
]
},
"app_install": {
"package_names": [
"package.name.one",
"package.name.two", ...
]
}
}
},
...
]
}
fetchAndJoinCustomAudience()
API menentukan identitas pembeli dari eTLD+1
dari fetchUri
. Identitas pembeli CustomAudience
digunakan untuk melakukan pendaftaran
dan pemeriksaan otorisasi aplikasi yang sama dengan yang dilakukan oleh joinCustomAudience()
dan tidak dapat diubah oleh respons pengambilan. Pemilik CustomAudience
adalah
nama paket aplikasi panggilan. Tidak ada validasi lain terhadap
fetchUri
selain pemeriksaan eTLD+1, dan khususnya, tidak ada pemeriksaan
k-anon. fetchAndJoinCustomAudience()
API mengeluarkan permintaan GET HTTP ke
fetchUri
dan mengharapkan objek JSON yang mewakili audiens kustom. Batasan wajib
dan opsional serta nilai default yang sama untuk kolom objek audiens kustom
diterapkan pada respons. Pelajari
persyaratan dan batasan saat ini di Panduan Developer kami.
Respons error HTTP apa pun dari pembeli akan menyebabkan fetchAndJoinCustomAudience
gagal. Secara khusus, respons status HTTP 429 (Terlalu Banyak Permintaan) akan memblokir
permintaan dari aplikasi saat ini untuk periode yang akan ditentukan. Panggilan API
juga akan gagal jika format respons pembeli salah. Kegagalan dilaporkan ke
pemanggil API yang bertanggung jawab untuk mencoba lagi karena kegagalan sementara (seperti
server tidak merespons) atau menangani kegagalan persisten (seperti kegagalan validasi
data atau error non-transitif lainnya dengan komunikasi ke server).
Objek CustomAudienceFetchRequest
memungkinkan pemanggil API menentukan beberapa
informasi untuk Audiens Kustom menggunakan properti opsional yang ditampilkan dalam
contoh di atas. Jika ditetapkan dalam permintaan, nilai ini tidak dapat ditimpa oleh
respons pembeli yang diterima oleh platform; Protected Audience API mengabaikan
kolom tersebut dalam respons. Jika tidak ditetapkan dalam permintaan, nilai tersebut harus
ditetapkan dalam respons, karena kolom ini diperlukan untuk membuat audiens
kustom. Representasi JSON untuk konten
CustomAudience
seperti yang ditentukan sebagian oleh pemanggil API disertakan dalam permintaan
GET ke fetchUri
di header khusus X-CUSTOM-AUDIENCE-DATA
. Ukuran bentuk serial data
yang ditentukan untuk Audiens Kustom dibatasi hingga 8 KB. Jika ukurannya
terlampaui, panggilan API fetchAndJoinCustomAudience
akan gagal.
Tidak adanya pemeriksaan k-anon memungkinkan Anda menggunakan fetchUri
untuk verifikasi pembeli
dan memungkinkan pembagian informasi antara pembeli dan SDK. Untuk memfasilitasi verifikasi
audiens kustom, pembeli dapat memberikan token
verifikasi. SDK di perangkat harus menyertakan token ini di fetchUri
agar
endpoint yang dihosting oleh pembeli dapat mengambil konten audiens kustom dan
menggunakan token verifikasi untuk memverifikasi bahwa operasi fetchAndJoinCustomAudience()
sesuai dengan pembeli dan berasal dari partner di perangkat
yang tepercaya. Untuk membagikan informasi, pembeli dapat menyetujui pemanggil di perangkat
bahwa beberapa informasi yang akan digunakan untuk membuat audiens kustom akan
ditambahkan sebagai parameter kueri ke fetchUri
. Hal ini memungkinkan pembeli mengaudit
panggilan dan mendeteksi apakah token validasi telah digunakan oleh teknologi iklan berbahaya untuk
membuat beberapa audiens kustom yang berbeda.
Catatan tentang definisi dan penyimpanan token verifikasi
Token verifikasi tidak digunakan untuk tujuan apa pun oleh Protected Audience API dan bersifat opsional.
- Token verifikasi dapat digunakan oleh pembeli untuk memverifikasi bahwa audiens yang dibuat dilakukan atas nama mereka.
- Proposal Protected Audience API tidak menentukan format untuk token verifikasi atau cara pembeli mentransfer token verifikasi ke pemanggil. Misalnya, token verifikasi dapat dipramuat di SDK atau backend pemilik, atau dapat diambil secara real-time oleh SDK pemilik dari server pembeli.
Keluar dari audiens kustom
Pemilik audiens kustom dapat memilih untuk keluar dengan memanggil
leaveCustomAudience()
, seperti ditunjukkan dalam cuplikan kode ilustrasi di bawah ini:
// Invoke ad services API to leave a custom audience.
leaveCustomAudience(buyer, name);
Untuk membantu menghemat penggunaan penyimpanan dan resource perangkat lainnya, masa berlaku audiens kustom akan berakhir dan akan dihapus dari penyimpanan di perangkat setelah periode yang ditentukan. Nilai defaultnya akan ditentukan. Pemilik dapat mengganti nilai default ini.
Kontrol pengguna
- Proposal ini dimaksudkan untuk memberikan visibilitas kepada pengguna ke daftar aplikasi terinstal yang telah membuat setidaknya satu audiens kustom.
- Pengguna dapat menghapus aplikasi dari daftar ini. Penghapusan ini akan menghapus semua audiens kustom yang terkait dengan aplikasi dan mencegah aplikasi bergabung dengan audiens kustom baru.
- Pengguna dapat mereset Protected Audience API sepenuhnya. Jika hal ini terjadi, semua audiens kustom yang ada di perangkat akan dihapus.
- Pengguna dapat memilih untuk tidak menggunakan Privacy Sandbox sepenuhnya di Android, yang mencakup Protected Audience API. Jika pengguna memilih untuk tidak menggunakan Privacy Sandbox, Protected Audience API akan gagal secara otomatis.
Desain kemampuan ini masih dalam proses, dan detailnya akan disertakan dalam update selanjutnya.
Update Terjadwal
Solusi yang dijelaskan sebelumnya memerlukan SDK teknologi iklan atau aplikasi untuk memanggil API saat aplikasi berada di latar depan dan memberikan properti lengkap audiens kustom, baik secara langsung maupun menggunakan delegasi. Namun, tidak selalu pengiklan dan penyedia teknologi iklan dapat menentukan audiens mana yang berada di waktu nyata saat mereka menggunakan aplikasi.
Untuk memfasilitasi hal ini, teknologi iklan dapat memanggil
API scheduleCustomAudienceUpdate()
. API ini memungkinkan pemanggil menentukan
penundaan saat panggilan API harus dilakukan, sehingga memberikan waktu tambahan
untuk teknologi iklan respons guna memproses peristiwa tingkat aplikasi dan menentukan
Protected Audience yang akan diikuti atau dihapus pengguna.
/**
* API To schedule delayed update events for Custom Audience
*
* @param delayedCustomUpdates List of Delayed Update events that trigger a
* call to DSP endpoint provided inside the DelayedCustomUpdate object
*/
public void scheduleCustomAudienceUpdates(
@NonNull DelayedCustomUpdate delayedCustomAudienceUpdate,
@NonNull @CallBackExecutor Executor executor,
@NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)
DelayedCustomAudienceUpdate
public final class DelayedCustomAudienceUpdate {
// Required Field
@NonNull public Uri getUpdateUri() {
return mUpdateUri;
}
// Required Field
@NonNull public Duration getMinDelay() {
return mMinDelay;
}
// Required Field
@NonNull public List<PartialCustomAudience> getPartialCustomAudiences() {
return mPartialCustomAudiences;
}
}
DelayedCustomAudienceUpdate
berisi informasi yang
diperlukan untuk
mendaftarkan tugas yang tertunda
untuk dijalankan dengan platform. Setelah penundaan yang ditentukan,
tugas latar belakang akan berjalan
secara berkala dan mengirim permintaan. Tujuan
DelayedCustomAudienceUpdate
dapat berisi informasi berikut:
- UpdateUri: Endpoint URI yang akan dikirimi panggilan GET untuk mengambil update.
Identitas pembeli disimpulkan secara intrinsik dari eTLD+1 dan tidak perlu
secara eksplisit dan tidak dapat
diubah oleh respons pembaruan. GET
mengharapkan objek JSON yang berisi daftar objek
customAudience
di kembali. - DelayTime: Waktu yang menunjukkan penundaan dari waktu pembuatan
Panggilan API
scheduleCustomAudienceUpdate()
untuk menjadwalkan update.
PartialCustomAudience: API juga memungkinkan SDK di perangkat untuk mengirim daftar Audiens Kustom yang dibuat sebagian. Hal ini memungkinkan SDK dalam aplikasi untuk menyalurkan peran ganda, dari kontrol penuh hingga sebagian atas pengelolaan Audiens Kustom berdasarkan kemitraan mereka dengan DSP.
- Tindakan ini juga membuat API ini tetap kompatibel dengan
fetchAndJoinCustomAudience()
API yang memungkinkan berbagi informasi serupa.
- Tindakan ini juga membuat API ini tetap kompatibel dengan
Izin dan kontrol aplikasi
Proposal ini akan memberikan kontrol kepada aplikasi atas audiens kustomnya:
- Aplikasi dapat mengelola kaitannya dengan audiens kustom.
- Aplikasi dapat memberikan izin kepada platform teknologi iklan pihak ketiga untuk mengelola audiens kustom atas nama aplikasi tersebut.
Desain kemampuan ini masih dalam proses, dan detailnya akan disertakan dalam update selanjutnya.
Kontrol platform teknologi iklan
Proposal ini menguraikan cara teknologi iklan mengontrol audiens kustomnya:
- Teknologi iklan mendaftar dengan Privacy Sandbox dan menyediakan domain eTLD+1 yang cocok dengan semua URL untuk audiens kustom.
- Teknologi iklan dapat berpartner dengan aplikasi atau SDK untuk memberikan token verifikasi yang digunakan untuk memverifikasi pembuatan audiens kustom. Saat proses ini didelegasikan ke partner, pembuatan audiens kustom dapat dikonfigurasi untuk memerlukan konfirmasi oleh teknologi iklan.
- Teknologi iklan dapat memilih untuk menonaktifkan panggilan
joinCustomAudience
atas namanya dan hanya mengizinkanfetchAndJoinCustomAudience
API untuk mengaktifkan semua audiens kustom panggilan. Kontrol dapat diperbarui selama pendaftaran Privacy Sandbox. Perhatikan bahwa kontrol ini mengizinkan semua teknologi iklan atau tidak sama sekali. Karena keterbatasan platform, izin delegasi tidak dapat didasarkan pada masing-masing teknologi iklan.
Respons metadata dan iklan kandidat
Iklan kandidat dan metadata yang ditampilkan dari platform sisi beli harus menyertakan kolom berikut:
- Metadata: Metadata iklan khusus teknologi iklan sisi beli. Misalnya, metadata ini dapat menyertakan informasi tentang kampanye iklan, dan kriteria penargetan seperti lokasi dan bahasa.
- URL Render: Endpoint untuk merender materi iklan.
- Filter: Informasi opsional yang diperlukan agar Protected Audience API dapat memfilter iklan berdasarkan data di perangkat. Untuk detail selengkapnya, baca bagian tentang logika pemfilteran sisi beli.
Alur kerja pemilihan iklan
Proposal ini bertujuan untuk meningkatkan privasi dengan memperkenalkan Ad Selection API yang mengatur eksekusi lelang untuk platform teknologi iklan.
Platform teknologi iklan saat ini biasanya melakukan bidding dan pemilihan iklan secara eksklusif pada servernya. Dengan proposal ini, audiens kustom dan sinyal pengguna sensitif lainnya, seperti informasi paket terinstal yang tersedia, hanya dapat diakses melalui Ad Selection API. Selain itu, untuk kasus penggunaan pemasaran ulang, iklan kandidat akan diambil dari band (bukan dalam konteks tempat iklan akan ditampilkan). Platform teknologi iklan harus mempersiapkan beberapa bagian dari lelang saat ini dan logika pemilihan iklan diterapkan dan dieksekusi di perangkat. Platform teknologi iklan dapat mempertimbangkan perubahan berikut pada alur kerja pemilihan iklan mereka:
- Tanpa informasi paket terinstal yang tersedia di server, platform teknologi iklan sebaiknya mengirim beberapa iklan kontekstual kembali ke perangkat dan memanggil alur kerja pemilihan iklan untuk mengaktifkan pemfilteran berbasis penginstalan aplikasi guna memaksimalkan peluang untuk menampilkan iklan yang relevan.
- Karena iklan pemasaran ulang diambil dari band, model bidding saat ini mungkin perlu diperbarui. Platform teknologi iklan mungkin ingin membuat submodel bidding (implementasinya mungkin didasarkan pada pola yang disebut model dua menara) yang dapat berfungsi pada fitur iklan dan sinyal kontekstual secara terpisah serta menggabungkan output submodel di perangkat untuk memprediksi bid. Hal ini dapat memanfaatkan lelang sisi server dan lelang untuk peluang iklan tertentu.
Pendekatan ini memungkinkan data interaksi aplikasi pengguna untuk menginformasikan pemilihan iklan, sekaligus membatasi pembagian data ini dengan pihak ketiga.
Alur kerja pemilihan iklan ini mengatur eksekusi kode JavaScript yang disediakan teknologi iklan di perangkat berdasarkan urutan berikut:
- Eksekusi logika bidding sisi beli
- Pemfilteran dan pemrosesan iklan sisi beli
- Eksekusi logika keputusan sisi jual
Untuk pemilihan iklan yang melibatkan audiens kustom, platform akan mengambil kode JavaScript yang disediakan oleh sisi beli berdasarkan endpoint URL publik yang ditentukan oleh metadata "URL logika bidding" audiens kustom. Endpoint URL untuk kode keputusan sisi jual juga akan diteruskan sebagai input untuk memulai alur kerja pemilihan iklan.
Desain pemilihan iklan yang tidak melibatkan audiens kustom sedang dalam proses desain aktif.
Memulai alur kerja pemilihan iklan
Saat aplikasi perlu menampilkan iklan, SDK platform teknologi iklan dapat memulai alur kerja pemilihan
iklan dengan memanggil metode selectAds()
setelah membuat instance
objek AdSelectionConfig
dengan parameter yang diharapkan:
- Penjual: ID untuk platform iklan sisi jual, dengan mengikuti format eTLD+1
- URL logika keputusan: Saat lelang iklan dimulai, platform akan menggunakan URL ini untuk mengambil kode JavaScript dari platform sisi jual untuk menilai iklan pemenang.
- Pembeli audiens kustom: Daftar platform sisi beli dengan permintaan berbasis audiens kustom untuk lelang ini, dengan mengikuti format eTLD+1.
- Sinyal pemilihan iklan: Informasi tentang lelang (ukuran iklan, format iklan, dll.).
- Sinyal penjual: Sinyal khusus platform sisi suplai.
- URL Sinyal Penskoran Tepercaya: Endpoint URL untuk sinyal tepercaya sisi jual tempat informasi realtime khusus materi iklan dapat diambil.
- Sinyal per pembeli: Sisi permintaan yang berpartisipasi dapat menggunakan parameter ini untuk memberikan input lelang. Misalnya, parameter ini dapat menyertakan informasi kontekstual komprehensif yang berguna untuk menentukan bid.
Cuplikan kode ilustrasi berikut menunjukkan SDK platform teknologi iklan yang memulai
alur kerja pemilihan iklan dengan terlebih dahulu menentukan AdSelectionConfig
, lalu
memanggil selectAds
untuk mendapatkan Iklan pemenang:
AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
Seller = "example-ssp1.com",
DecisionLogicURL = Uri.parse("https://..."),
CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","bexample-dsp2.com"),
AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
PerBuyerSignals = " {"buyer1Name": {"key1" : "value1"},
"buyer2Name": {"key1" : "value1", "key2" : "value2" }"
};
// Invoke ad services API to initiate ad selection workflow.
Ad winningAd = selectAds(myAdSelectionConfig);
Logika bidding sisi beli
Logika bidding biasanya disediakan oleh platform sisi beli. Tujuan kode ini adalah menentukan bid untuk iklan kandidat. Tindakan ini mungkin menerapkan logika bisnis tambahan untuk menentukan hasilnya.
Platform ini akan menggunakan metadata "URL logika bidding" audiens kustom untuk mengambil kode JavaScript yang harus menyertakan tanda tangan fungsi di bawah ini:
generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return {'bid': ...};
}
Metode generateBid()
menampilkan jumlah bid yang dihitung. Platform akan
memanggil fungsi tersebut untuk semua iklan (kontekstual atau pemasaran ulang) secara berurutan. Jika
ada beberapa penyedia logika bidding, sistem tidak menjamin
urutan eksekusi di antara penyedia tersebut.
Fungsi ini mengharapkan parameter berikut:
- Iklan: Iklan yang dipertimbangkan oleh kode bidding sisi beli. Ini akan berupa Iklan dari audiens kustom yang memenuhi syarat
- Sinyal lelang: Sinyal khusus platform sisi jual.
- Sinyal per pembeli: Sisi permintaan yang berpartisipasi dapat menggunakan parameter ini untuk memberikan input lelang. Misalnya, parameter ini dapat menyertakan informasi kontekstual komprehensif yang berguna untuk menentukan bid.
- Sinyal bidding tepercaya: Platform teknologi iklan mengandalkan data real time sebagai dasar untuk pengambilan dan penskoran iklan. Misalnya, kampanye iklan mungkin kehabisan anggaran dan harus segera dihentikan penayangannya. Teknologi iklan dapat menentukan endpoint URL tempat data real-time ini dapat diambil dan kumpulan kunci yang memerlukan pencarian real-time. Server terkelola platform teknologi iklan yang menayangkan permintaan ini akan menjadi server tepercaya yang dikelola oleh platform teknologi iklan.
- Sinyal kontekstual: Sinyal ini dapat mencakup stempel waktu yang terperinci atau informasi perkiraan lokasi, atau biaya per klik pada iklan.
- Sinyal pengguna: Sinyal ini dapat mencakup informasi seperti informasi paket terinstal yang tersedia.
Biaya iklan
Selain bid, platform sisi beli memiliki opsi untuk menampilkan biaya
per klik sebagai bagian dari generateBid()
. Contoh:
generateBid(ad, auction_signals, per_buyer_signals, trusted_bidding_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return {'bid': ..., 'adCost': ...,};
}
Jika iklan ini adalah pemenangnya, adCost
dibulatkan secara stokastik menjadi 8 bit untuk
privasi. Nilai adCost
yang dibulatkan akan diteruskan ke
parameter contextual_signals
di reportWin
selama pelaporan tayangan.
Logika pemfilteran sisi beli
Platform sisi beli akan dapat memfilter iklan berdasarkan sinyal tambahan di perangkat yang tersedia selama fase pemilihan iklan. Misalnya, platform teknologi iklan dapat menerapkan kemampuan pembatasan frekuensi di sini. Jika ada beberapa penyedia pemfilteran, sistem tidak menjamin urutan eksekusi di antara penyedia tersebut.
Logika pemfilteran sisi beli dapat diterapkan sebagai bagian dari
logika bidding dengan menampilkan nilai bid 0
untuk iklan tertentu.
Selain itu, platform sisi beli akan dapat memberikan sinyal bahwa iklan tertentu harus difilter berdasarkan sinyal tambahan di perangkat yang tersedia untuk Protected Audience dan yang tidak akan keluar dari perangkat. Ketika kami memperkuat desain logika pemfilteran tambahan, platform sisi beli akan mengikuti struktur yang sama ini untuk memberikan sinyal bahwa pemfilteran harus dilakukan.
Logika penskoran sisi jual
Logika penskoran biasanya disediakan oleh platform sisi jual. Tujuan
kode ini adalah untuk menentukan iklan pemenang berdasarkan output logika bidding. Tindakan ini mungkin
menerapkan logika bisnis tambahan untuk menentukan hasilnya. Jika ada beberapa
penyedia logika keputusan, sistem tidak menjamin urutan eksekusi
di antara penyedia tersebut. Platform ini akan menggunakan parameter input "URL logika keputusan"
dari selectAds()
API untuk mengambil kode JavaScript yang harus
menyertakan tanda tangan fungsi di bawah ini:
scoreAd(ad, bid, auction_config, trusted_scoring_signals,
contextual_signals, user_signals, custom_audience_signals) {
// ...
return score_for_this_ad;
}
Fungsi ini mengharapkan parameter berikut:
- Iklan: Iklan yang dievaluasi; output dari fungsi
generateBid()
. - Bid: Output jumlah bid dari fungsi
generateBid()
. - Konfigurasi lelang: Parameter input ke metode
selectAds()
. - Sinyal Penskoran Tepercaya: Platform teknologi iklan mengandalkan data real time sebagai dasar untuk pemfilteran dan penskoran iklan. Misalnya, penayang aplikasi dapat memblokir kampanye iklan agar tidak menampilkan iklan di aplikasi. Data ini diambil dari parameter URL sinyal penskoran tepercaya dari konfigurasi lelang. Server yang menayangkan permintaan ini harus berupa server tepercaya yang dikelola teknologi iklan.
- Sinyal kontekstual: Sinyal ini dapat mencakup stempel waktu yang terperinci atau informasi perkiraan lokasi.
- Sinyal pengguna: Sinyal ini dapat mencakup informasi seperti app store yang memulai penginstalan aplikasi.
- Sinyal audiens kustom: Jika Iklan yang dinilai berasal dari audiens kustom di perangkat, sinyal ini akan berisi informasi seperti pembaca dan nama audiens kustom tersebut.
Runtime kode pemilihan iklan
Dalam proposal ini, sistem akan mengambil kode lelang yang disediakan platform teknologi iklan dari endpoint URL yang dapat dikonfigurasi dan mengeksekusi di perangkat. Dengan mempertimbangkan batasan resource pada perangkat seluler, kode lelang harus mematuhi pedoman berikut:
- Kode akan selesai dieksekusi dalam jangka waktu yang telah ditentukan. Batasan ini akan diterapkan secara seragam ke semua jaringan iklan pembeli. Detail tentang batasan ini akan dibagikan dalam update selanjutnya.
- Kode tersebut harus mandiri dan tidak memiliki dependensi eksternal.
Karena kode lelang, misalnya logika bidding mungkin memerlukan akses ke data pengguna pribadi seperti sumber penginstalan aplikasi, runtime tidak akan memberikan akses jaringan atau penyimpanan.
Bahasa pemrograman
Kode lelang yang disediakan platform teknologi iklan harus ditulis dalam JavaScript. Dengan demikian, platform teknologi iklan akan diizinkan, misalnya, untuk berbagi kode bidding di seluruh platform yang mendukung Privacy Sandbox.
Rendering iklan pemenang
Iklan dengan skor tertinggi dianggap sebagai pemenang lelang. Dalam proposal awal ini, iklan pemenang diteruskan ke SDK untuk dirender.
Rencananya adalah untuk mengembangkan solusi guna memastikan bahwa informasi tentang keanggotaan audiens kustom pengguna, atau histori interaksi aplikasi, tidak dapat ditentukan oleh aplikasi atau SDK melalui informasi tentang iklan pemenang (serupa dengan proposal frame dengan fence di Chrome).
Pelaporan tayangan dan peristiwa
Setelah iklan dirender, tayangan pemenang dapat dilaporkan kembali ke platform sisi jual dan sisi beli yang berpartisipasi. Hal ini memungkinkan pembeli dan penjual menyertakan informasi dari lelang, seperti nama bid atau audiens kustom, dengan laporan tayangan pemenang. Selain itu, platform sisi jual dan sisi beli pemenang memenuhi syarat untuk menerima pelaporan tingkat peristiwa tambahan tentang iklan pemenang. Hal ini memberikan kemampuan untuk menyertakan informasi tentang lelang (bid, nama audiens kustom, dll.) dengan klik, penayangan, dan peristiwa iklan lainnya. Platform memanggil logika pelaporan dalam urutan ini:
- Pelaporan sisi jual.
- Pelaporan sisi beli.
Hal ini memberikan cara bagi platform sisi beli dan sisi jual untuk mengirimkan informasi penting di perangkat kembali ke server untuk memungkinkan kemampuan seperti penentuan anggaran secara real time, pembaruan model bidding, dan alur kerja penagihan yang akurat. Dukungan pelaporan tayangan ini adalah pelengkap untuk Attribution Reporting API.
Ada dua langkah yang diperlukan untuk mendukung pelaporan peristiwa: JavaScript sisi jual dan sisi beli harus mendaftarkan peristiwa yang harus diterima laporan peristiwa, dan sisi jual bertanggung jawab untuk melaporkan informasi tingkat peristiwa.
Protected Audience menyediakan mekanisme untuk berlangganan peristiwa mendatang yang terkait dengan
lelang pemenang dengan mendaftarkan beacon. Dalam fungsi JavaScript reportResult()
penjual, platform sisi jual dapat mendaftarkan beacon menggunakan
fungsi registerAdBeacon()
platform. Demikian pula, platform sisi beli dapat memanggil
metode registerAdBeacon()
dari fungsi JavaScript reportWin()
.
registerAdBeacon(beacons)
Input:
event_key
: String yang menunjukkan jenis interaksi mana yang akan didaftarkan. Ini digunakan sebagai kunci untuk mencari titik akhir ping platform saat melaporkan hasil lelang.reporting_url
: URL yang dimiliki oleh platform teknologi iklan untuk menangani peristiwa.
Kunci peristiwa adalah ID string yang dimiliki oleh SDK sisi jual
yang bertanggung jawab untuk melaporkan hasil lelang. Agar callback dapat dilakukan,
teknologi iklan mendaftarkan beacon dengan kunci yang cocok dengan kunci yang digunakan oleh sisi jual
saat melaporkan peristiwa. Parameter ini tidak perlu bersifat k-anonim, meskipun ada
batas jumlah dan panjang kunci yang dapat didaftarkan untuk
audiens kustom tertentu. Jika reportEvent()
dipanggil, platform sisi jual
yang menjalankan lelang akan selalu memenuhi syarat untuk menerima laporan
peristiwa ini. Hanya
platform sisi beli yang menang yang memenuhi syarat untuk menerima laporan ini.
Pelaporan sisi jual
Platform memanggil fungsi JavaScript reportResult()
dalam kode yang disediakan
sisi suplai dan didownload dari parameter URL logika Keputusan
penjual untuk selectAds()
API:
reportResult(render_url, bid, auction_config, contextual_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_url": reporting_url,
"signals_for_buyer": signals_for_buyer}};
}
Output: Objek JSON yang berisi
- Status:
0
untuk berhasil, nilai lain untuk gagal. - URL Pelaporan: Platform memanggil URL ini yang ditampilkan dari fungsi.
- Sinyal untuk Pembeli: Objek JSON yang akan diteruskan ke fungsi
reportWin
pembeli.
Sisi suplai dapat mengenkode sinyal yang relevan di URL pelaporan untuk membantunya mendapatkan analisis lebih lanjut tentang lelang dan iklan pemenang. Contohnya, sinyal di bawah ini mungkin termasuk di dalamnya:
- URL render iklan
- Jumlah bid pemenang
- Nama aplikasi
- ID kueri
- Sinyal untuk pembeli: Untuk mendukung berbagi data antara sisi suplai dan sisi permintaan, platform akan meneruskan nilai return sebagai parameter input ke kode pelaporan sisi permintaan.
Pelaporan sisi beli
Platform memanggil fungsi JavaScript reportWin()
dalam kode
yang disediakan sisi permintaan dan didownload dari metadata URL logika Bidding dari
audiens kustom yang terkait dengan lelang.
reportWin(render_url, bid, auction_signals, per_buyer_signals,
signals_for_buyer, contextual_signals, custom_audience_signals) {
// ...
beacons = {"click":clickUri}
registerAdBeacon(beacons)
return {
"status": 0,
"results": {"reporting_uri": reporting_uri}};
}
Input:
auction_signals
danper_buyer_signals
diambil dariAuctionConfig
. Setiap informasi yang harus diteruskan oleh platform sisi beli ke URL pelaporan mungkin berasal dari data ini.signals_for_buyer
adalah output dari reportResult sisi jual. Dengan begitu, platform sisi jual memiliki peluang untuk berbagi data dengan platform sisi beli untuk tujuan pelaporan.contextual_signals
berisi informasi seperti nama aplikasi dancustom_audience_signals
berisi informasi audiens kustom. Informasi lainnya dapat ditambahkan di masa mendatang.
Output:
- Status:
0
untuk berhasil, nilai lain untuk gagal. - URL Pelaporan: Platform memanggil URL ini yang ditampilkan dari fungsi.
Melaporkan Peristiwa
Melaporkan peristiwa hanya dapat dilakukan setelah pelaporan tayangan untuk
lelang selesai. SDK sisi jual bertanggung jawab untuk melaporkan peristiwa apa pun. Platform
ini mengekspos API yang menggunakan ReportEventRequest
yang menentukan
lelang yang baru saja dijalankan, kunci peristiwa yang dilaporkan, data yang terkait dengan
kunci tersebut, apakah laporan harus dikirim ke pembeli atau penjual (atau keduanya), serta peristiwa input opsional untuk peristiwa iklan. Klien menentukan kunci peristiwa dan
pengumpulan data yang akan dilaporkan.
ReportEventRequest request = new ReportEventRequest(
AdSelectionId = ad_selection_id,
event_key = "view"
event_data = "{ "viewTimeInSeconds" :1 }",
reporting_destinations =
FLAG_REPORTING_DESTINATION_SELLER |
FLAG_REPORTING_DESTINATION_BUYER,
input_event = clickInputEvent // or null for view
)
reportEvent(request)
Input:
ad_selection_id
harus berupaAdSelectionId
dari lelang yang baru saja dijalankan yang diambil dariAdSelectionOutcome
.event_key
adalah string yang ditentukan sisi jual yang mendeskripsikan peristiwa interaksi.event_data
adalah string yang mewakili data yang terkait denganevent_key
reporting_destinations
adalah bit mask yang ditetapkan menggunakan flag yang disediakan oleh platform ini. Nilai dapat berupa salah satu dariFLAG_REPORTING_DESTINATION_SELLER
atauFLAG_REPORTING_DESTINATION_BUYER
, atau keduanya.input_event
(opsional) digunakan untuk integrasi dengan Attribution Reporting API. Objek ini dapat berupa objekInputEvent
(untuk peristiwa klik) atau null (untuk peristiwa penayangan). Lihat Integrasi Attribution Reporting API untuk mengetahui detail selengkapnya tentang parameter ini.
Setelah SDK sisi jual memanggil reportEvent
dan, bergantung pada
tanda reporting_destinations
, platform akan mencoba mencocokkan event_key
ke
kunci yang didaftarkan oleh pembeli dan penjual di
fungsi JavaScript reportWin
dan reportResult
. Jika ada kecocokan, platform akan MEMPOSTING
event_data
ke reporting_url
terkait. Jenis konten permintaan
adalah teks biasa dengan isi berupa event_data
. Permintaan ini dilakukan sebagai upaya
terbaik dan gagal secara otomatis di peristiwa jika terjadi error jaringan, respons error
server, atau jika tidak ditemukan kunci yang cocok.
Integrasi Attribution Reporting API
Untuk mendukung pembeli yang berpartisipasi dalam lelang Protected Audience, kami menyediakan fungsi lintas-API di seluruh Protected Audience dan Attribution Reporting API (ARA). Fungsi ini memungkinkan teknologi iklan mengevaluasi performa atribusi di berbagai taktik pemasaran ulang, sehingga mereka dapat memahami jenis audiens mana yang menghasilkan ROI tertinggi.
Melalui integrasi lintas-API ini, teknologi iklan dapat:
- Membuat peta nilai kunci URI yang akan digunakan untuk 1) pelaporan interaksi iklan dan 2) pendaftaran sumber.
- Menyertakan data lelang dari lelang Protected Audience dalam pemetaan kunci sisi sumber untuk pelaporan ringkasan gabungan (menggunakan Attribution Reporting API). Lihat proposal desain ARA untuk informasi selengkapnya.
Saat pengguna melihat atau mengklik iklan:
- URL yang digunakan untuk melaporkan interaksi peristiwa tersebut yang menggunakan Protected Audience akan memberikan data yang diperlukan kepada pembeli untuk digunakan mendaftarkan penayangan atau klik sebagai sumber yang memenuhi syarat dengan Attribution Reporting API.
- Teknologi iklan dapat memilih untuk meneruskan
CustomAudience
(atau informasi kontekstual relevan lainnya tentang iklan seperti penempatan iklan atau durasi penayangan) menggunakan URL tersebut sehingga metadata ini dapat diterapkan ke laporan ringkasan saat teknologi iklan sedang meninjau performa kampanye gabungan.
Mengaktifkan pendaftaran sumber
reportEvent()
akan menerima parameter opsional baru InputEvent
. Pembeli
yang memenangkan dan mendaftarkan beacon iklan dapat memilih laporan reportEvent mana yang
didaftarkan dengan Attribution Reporting API sebagai sumber terdaftar. Header permintaan
yang memenuhi syarat Pelaporan Atribusi akan ditambahkan ke semua permintaan pelaporan
peristiwa yang dikirim dari reportEvent()
. Setiap respons dengan header ARA yang sesuai akan diuraikan dengan cara yang sama seperti respons pendaftaran sumber ARA reguler lainnya. Lihat penjelasan Attribution Reporting API untuk mengetahui cara
mendaftarkan URL sumber.
Karena ARA di Android mendukung peristiwa penayangan dan klik, InputEvents
digunakan untuk membedakan kedua jenis tersebut. Sama seperti dalam pendaftaran sumber
ARA, reportEvent()
API akan menafsirkan InputEvent
yang diverifikasi platform sebagai peristiwa klik. Jika InputEvent
tidak ada, null, atau tidak valid,
pendaftaran sumber akan dianggap sebagai penayangan.
Perhatikan bahwa eventData
pasca-lelang dapat berisi informasi sensitif, sehingga
platform akan menghapus eventData
dalam permintaan pendaftaran sumber yang dialihkan.
Contoh pelaporan engagement dan konversi
Dalam contoh ini, kita akan melihatnya dari perspektif pembeli yang tertarik untuk mengaitkan data dari pelelangan, iklan yang dirender, dan aplikasi konversi secara bersamaan.
Dalam alur kerja ini, pembeli berkoordinasi dengan penjual untuk mengirimkan ID unik ke lelang. Selama lelang, pembeli mengirimkan ID unik ini bersama dengan data lelang. Selama waktu render dan konversi, data dari iklan yang dirender juga dikirim bersama dengan ID unik yang sama. Selanjutnya, ID unik tersebut dapat digunakan untuk mengaitkan laporan ini secara bersamaan.
Alur kerja:
Sebelum lelang dimulai, pembeli mengirimkan ID unik ke penjual sebagai bagian dari
transaksi terprogram merekarespons bid bidding real-time ("RTB"). ID dapat ditetapkan sebagai variabel seperti auctionId
. ID diteruskan sebagai perBuyerSignals
di
auctionConfig
dan akan tersedia di logika bidding pembeli.
- Selama eksekusi
reportWin
, pembeli dapat mendaftarkan beacon iklan agar dipicu selama waktu render iklan dan untuk peristiwa interaksi tertentu (registerAdBeacon()
). Untuk mengaitkan sinyal lelang peristiwa iklan, setelauctionId
sebagai parameter kueri URL beacon. - Selama waktu render iklan, beacon yang didaftarkan selama waktu lelang dapat
dipicu atau ditingkatkan dengan data tingkat peristiwa. Penjual harus memicu
reportEvent()
dan meneruskan data tingkat peristiwa. Platform akan melakukan ping ke URL beacon iklan terdaftar milik pembeli yang berhubungan denganreportEvent()
yang dipicu. - Pembeli akan mendaftarkan iklan ke Attribution Reporting API dengan
merespons permintaan beacon iklan menggunakan
header
Attribution-Reporting-Register-Source
. Untuk mengaitkan sinyal lelang peristiwa konversi, tetapkanauctionId
di Daftarkan sumber URL.
Setelah proses di atas, pembeli akan memiliki laporan lelang, laporan interaksi, dan laporan konversi, yang dapat dikorelasikan menggunakan ID unik yang dapat digunakan untuk mengaitkan satu sama lain.
Alur kerja serupa berlaku untuk penjual jika memerlukan akses ke data atribusi, dan
penjual juga dapat menggunakan ID unik untuk mengirim dengan registerAdBeacon()
. Panggilan
reportEvent()
berisi properti tujuan yang dapat digunakan untuk mengirim
laporan kepada pembeli dan penjual.
Server tepercaya yang dikelola platform teknologi iklan
Logika pemilihan iklan saat ini memerlukan informasi real-time seperti status penghapusan anggaran untuk menentukan apakah kandidat iklan harus dipilih untuk lelang. Platform sisi beli dan sisi jual akan dapat memperoleh informasi ini dari server yang mereka operasikan. Untuk meminimalkan kebocoran informasi sensitif apa pun melalui server ini, proposal akan meminta pembatasan berikut:
- Perilaku server ini, yang akan dijelaskan nanti di bagian ini, tidak akan membocorkan informasi pengguna.
- Server tidak akan membuat profil pseudonim berdasarkan data yang dilihatnya, sehingga harus 'dipercaya'.
Sisi beli: Setelah sisi beli memulai logika bidding sisi beli, platform ini melakukan pengambilan HTTP data bidding tepercaya dari server tepercaya. URL dibuat dengan menambahkan URL dan kunci yang ada dalam metadata Sinyal Bidding Tepercaya audiens kustom yang sedang diproses. Pengambilan ini hanya dilakukan saat memproses iklan dari audiens kustom di perangkat. Pada tahap ini, sisi beli dapat menerapkan anggaran, memeriksa status jeda/lanjutkan kampanye, melakukan penargetan, dll.
Berikut adalah contoh URL untuk mengambil data bidding tepercaya, berdasarkan metadata sinyal bidding tepercaya dari audiens kustom:
https://www.kv-server.example/getvalues?keys=key1,key2
Respons dari server harus berupa objek JSON yang kuncinya adalah key1, key2, dll., dan yang nilainya akan tersedia untuk fungsi bidding pembeli.
Sisi jual: Serupa dengan alur sisi beli di atas, sisi jual mungkin ingin mengambil informasi tentang materi iklan yang dipertimbangkan dalam lelang. Misalnya, penayang mungkin ingin membuat materi iklan tertentu tidak ditampilkan dalam aplikasinya karena masalah keamanan merek. Informasi ini dapat diambil dan disediakan untuk logika lelang sisi jual. Serupa dengan pencarian server tepercaya sisi beli, pencarian server tepercaya sisi jual juga terjadi melalui pengambilan HTTP. URL dibuat dengan menambahkan URL Sinyal Penskoran Tepercaya dengan URL render materi iklan yang datanya perlu diambil.
Berikut adalah contoh URL untuk mengambil informasi tentang materi iklan yang dipertimbangkan dalam lelang, berdasarkan URL render materi iklan:
https://www.kv-server.example/getvalues?renderUrls=render_url1,render_url2
Respons dari server harus berupa objek JSON yang kuncinya adalah URL render yang dikirim dalam permintaan.
Server ini akan beroperasi dengan cara tepercaya untuk menawarkan beberapa manfaat keamanan dan privasi:
- Nilai return server untuk setiap kunci dapat dipercaya bahwa hanya berdasarkan kunci tersebut.
- Server tidak menjalankan logging tingkat peristiwa.
- Server tidak memiliki efek samping lain berdasarkan permintaan ini.
Sebagai mekanisme sementara, pembeli dan penjual dapat mengambil sinyal bidding dari server mana pun, termasuk yang mereka operasikan sendiri. Namun, dalam versi rilis, permintaan hanya akan dikirim ke server tipe nilai kunci tepercaya.
Pembeli dan penjual dapat menggunakan server tipe nilai kunci tepercaya yang umum untuk platform yang kompatibel dengan Privacy Sandbox di Android dan untuk Web.