Mendukung penargetan audiens kustom dengan Protected Audience API

Berikan masukan

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.

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:

1. 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.
2. 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:

1. 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).

2. 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.

3. SDK platform teknologi iklan atau aplikasi penayangan iklan merender iklan yang dipilih.

4. 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 mengharuskan 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 request Criteria that determine when and where to trigger a call to a
* DSP endpoint to update one or more Custom Audiences
*/

public void scheduleCustomAudienceUpdate(
    @NonNull ScheduleCustomAudienceUpdateRequest request,
    @NonNull @CallBackExecutor Executor executor,
    @NonNull AdServicesOutcomeReceiver<Object, Exception> receiver)

ScheduleCustomAudienceUpdateRequest

public final class ScheduleCustomAudienceUpdateRequest {
  // Required Field
  @NonNull public Uri getUpdateUri() {
    return mUpdateUri;
  }

  // Required Field
  @NonNull public Duration getMinDelay() {
    return mMinDelay;
  }

  //  Required Field
  @NonNull public List<PartialCustomAudience> getPartialCustomAudienceList() {
    return mPartialCustomAudiences;
  }

  //  Optional Field (default false)
  public boolean shouldReplacePendingUpdates () {
    return mShouldReplacePendingUpdates;
  }
}

ScheduleCustomAudienceUpdateRequest 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 ScheduleCustomAudienceUpdateRequest 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 pembaruan.

• 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.

• ShouldReplacePendingUpdates: Boolean yang menentukan apakah ada status tertunda pembaruan terjadwal harus dibatalkan dan diganti dengan pembaruan yang dirinci dalam ScheduleCustomAudienceUpdateRequest saat ini. Jika ini disetel ke false dan ada pembaruan yang diminta sebelumnya yang masih menunggu keputusan untuk pembeli yang sama dalam aplikasi yang sama, panggilan ke scheduleCustomAudienceUpdate dengan ScheduleCustomAudienceUpdateRequest akan gagal. Nilai default-nya adalah false.

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 mengizinkan fetchAndJoinCustomAudience 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:

1. Eksekusi logika bidding sisi beli
2. Pemfilteran dan pemrosesan iklan sisi beli
3. 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:

1. Pelaporan sisi jual.
2. 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 dan per_buyer_signals diambil dari AuctionConfig. 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 dan custom_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 berupa AdSelectionId dari lelang yang baru saja dijalankan yang diambil dari AdSelectionOutcome.
• event_key adalah string yang ditentukan sisi jual yang mendeskripsikan peristiwa interaksi.
• event_data adalah string yang mewakili data yang terkait dengan event_key
• reporting_destinations adalah bit mask yang ditetapkan menggunakan flag yang disediakan oleh platform ini. Nilai dapat berupa salah satu dari FLAG_REPORTING_DESTINATION_SELLER atau FLAG_REPORTING_DESTINATION_BUYER, atau keduanya.
• input_event (opsional) digunakan untuk integrasi dengan Attribution Reporting API. Objek ini dapat berupa objek InputEvent (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.

1. 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, setel auctionId sebagai parameter kueri URL beacon.
2. 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 dengan reportEvent() yang dipicu.
3. 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, tetapkan auctionId 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.