Mendukung penargetan audiens kustom menggunakan FLEDGE

Berikan masukan

Update terbaru

  • Menambahkan proposal untuk delegasi audiens kustom.
  • Menghapus persyaratan k-anonymity untuk URL update harian

Ringkasan

Dalam periklanan seluler, pengiklan biasanya memiliki keinginan untuk menayangkan iklan kepada pengguna yang mungkin akan tertarik berdasarkan cara mereka berinteraksi sebelumnya dengan aplikasi pengiklan. Misalnya, developer SportingGoodsApp mungkin ingin menayangkan iklan 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.

FLEDGE di Android 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.
Gambar 1. Diagram alur yang menunjukkan alur kerja pengelolaan audiens dan pemilihan iklan kustom pada Privacy Sandbox di Android.

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 mengambil iklan berbasis audiens yang diperbarui secara berkala 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 manapun 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 akan 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 FLEDGE untuk API Android

Platform teknologi iklan perlu mendaftar untuk mengakses FLEDGE untuk Android API. Lihat Mendaftar ke akun Privacy Sandbox untuk mengetahui informasi selengkapnya.

Pengelolaan audiens kustom

Audiens Kustom

Audiens kustom mewakili sekelompok pengguna seperti 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 FLEDGE di grup minat 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 ini dapat diambil dan kumpulan kunci yang memerlukan pencarian real-time dilakukan. 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. FLEDGE memungkinkan definisi dan konfigurasi audiens kustom dengan cara yang melindungi privasi. 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). FLEDGE API bertujuan untuk mendukung SDK ini dengan menyediakan solusi fleksibel untuk pengelolaan audiens kustom dengan mengaktifkan pemanggil di perangkat untuk 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

Bergabung dengan audiens kustom dapat dilakukan dengan dua cara:

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 ilustrasi:

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);

fetchCustomAudience()

Aplikasi atau SDK dapat meminta untuk bergabung dengan audiens kustom atas nama teknologi iklan yang tidak memiliki kehadiran di perangkat dengan memanggil fetchCustomAudience() menggunakan parameter yang diharapkan, seperti dalam contoh berikut:

CustomAudienceFetchRequest fetchRequest = new CustomAudienceFetchRequest(
    // 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("{...}")
);

fetchCustomAudience(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": 1680603133,
 "expiration_time": 1680803133,
 "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/...",
 "ads": [
   {
     "render_uri": "https://example-dsp.com/...",
     "metadata": {},
     "ad_filters": {
       "frequency_cap": {
         "win": [
           {
             "ad_counter_key": "key1",
             "max_count": 2,
             "interval_in_seconds": 60
           },
         ],
         "view": [
           {
             "ad_counter_key": "key2",
             "max_count": 10,
             "interval_in_seconds": 3600
           },
         ]
       },
       "app_install": {
         "package_names": [
           "package.name.one",
           "package.name.two", ...
         ]
       }
     }
   },
   ...
 ]
}

API fetchCustomAudience() menentukan identitas pembeli dari eTLD+1 dari fetchUri. Identitas pembeli CustomAudience digunakan untuk melakukan pendaftaran yang sama dan pemeriksaan otorisasi aplikasi 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. fetchCustomAudience() API mengeluarkan permintaan GET HTTP ke fetchUri dan mengharapkan objek JSON yang mewakili audiens kustom. Batasan wajib dan opsional yang sama serta nilai default 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 CustomAudience gagal. Khususnya, respons status HTTP 429 (Terlalu Banyak Permintaan) akan memblokir permintaan dari aplikasi saat ini untuk periode yang ditentukan. Kegagalan dilaporkan ke pemanggil API yang bertanggung jawab untuk mencoba lagi jika terjadi kegagalan sementara (misalnya, server tidak merespons atau waktu tunggu habis) atau menangani kegagalan persisten (seperti kegagalan validasi data atau error non-sementara lainnya dalam komunikasi ke server).

Objek CustomAudienceFetchRequest memungkinkan pemanggil API menentukan beberapa informasi untuk Audiens Kustom dengan menggunakan properti opsional yang ditampilkan dalam contoh di atas. Jika ditentukan, nilai ini tidak dapat ditimpa oleh respons pembeli yang diterima oleh pembeli. FLEDGE akan mengabaikan kolom dalam respons. Representasi JSON dari konten CustomAudience seperti yang ditentukan sebagian oleh pemanggil API disertakan dalam permintaan GET ke fetchUri di header khusus X-CUSTOM-AUDIENCE-DATA. Ukuran data yang ditentukan untuk Audiens Kustom dibatasi hingga 8 KB.

Kurangnya 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 difetchUri sehingga endpoint yang dihosting oleh pembeli dapat mengambil konten audiens kustom dan menggunakan token verifikasi untuk memverifikasi bahwa operasi fetchCustomAudience() 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 untuk mengaudit panggilan telepon 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 FLEDGE dan bersifat opsional.

    • Token verifikasi dapat digunakan oleh pembeli untuk memverifikasi bahwa audiens yang dibuat atas nama mereka.
    • Proposal FLEDGE tidak menentukan format untuk token verifikasi serta 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 menghapus semua audiens kustom yang terkait dengan aplikasi dan mencegah aplikasi bergabung dengan audiens kustom baru.
  • Pengguna dapat mereset FLEDGE sepenuhnya. Jika hal ini terjadi, semua audiens kustom yang ada di perangkat akan dihapus.
  • Pengguna memiliki kemampuan untuk memilih tidak ikut sepenuhnya dari Privacy Sandbox di Android, yang mencakup FLEDGE. Jika demikian, FLEDGE API akan menampilkan pesan pengecualian standar: SECURITY_EXCEPTION.

Desain kemampuan ini masih dalam proses, dan detailnya akan disertakan dalam update selanjutnya.

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 bagi teknologi iklan untuk mengontrol audiens kustomnya:

  • Teknologi iklan mendaftar ke 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 fetchCustomAudience 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 per teknologi iklan.

Desain kemampuan ini masih dalam proses, dan detailnya akan disertakan dalam update selanjutnya.

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 FLEDGE untuk memfilter iklan berdasarkan data di perangkat. Untuk detail selengkapnya, lihat 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 mungkin ingin 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 (penerapannya mungkin didasarkan pada pola yang disebut model dua menara) yang dapat berfungsi pada fitur iklan dan sinyal kontekstual secara terpisah serta menggabungkan output sub-model 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.

Gambar 2. Diagram alur yang menunjukkan inisiasi alur kerja pemilihan iklan.

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.
  • Sinyal pengguna: Sinyal ini dapat mencakup informasi seperti informasi paket terinstal yang tersedia.

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 FLEDGE dan yang tidak akan keluar dari perangkat. Ketika kita memperkuat desain logika pemfilteran tambahan, platform sisi beli akan mengikuti struktur yang sama ini guna 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

Setelah iklan dirender, tayangan pemenang dapat dilaporkan kembali ke platform sisi jual dan beli yang berpartisipasi. Platform akan 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, seperti informasi bid, nama audiens kustom, dan sebagainya, kembali ke server untuk memungkinkan kemampuan seperti penentuan anggaran secara real time, update model bidding, dan alur kerja penagihan yang akurat. Dukungan pelaporan tayangan ini adalah pelengkap untuk Attribution Reporting API.

Pelaporan sisi jual

Platform akan 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) {
    // ...
    return reporting_url, signals_for_buyer;
}

Output:

  • URL Pelaporan: Platform akan memanggil URL ini yang ditampilkan dari fungsi.

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 akan memanggil fungsi JavaScript reportResult() dalam kode yang disediakan sisi permintaan dan didownload dari metadata URL logika Bidding dari audiens kustom yang terkait dengan lelang.

reportResult(render_url, bid, auction_signals, per_buyer_signals,
        signals_for_buyer, contextual_signals, custom_audience_signals) {
    // ...
    return reporting_url;
}

Input:

  • auction_signals dan per_buyer_signals akan 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 akan berisi informasi audiens kustom. Informasi lainnya dapat ditambahkan di masa mendatang.

Output:

  • URL Pelaporan: Platform akan memanggil URL ini yang ditampilkan dari fungsi.

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.