Privacy Sandbox di Android Beta kini telah hadir. Pelajari cara memulai, dan terus berikan masukan.

Mendukung penargetan audiens kustom menggunakan FLEDGE

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Berikan masukan

Update terbaru

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 pemilihan iklan dan pengelolaan audiens 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 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.

Bergabung dengan audiens kustom

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

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.

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

Izin dan kontrol platform teknologi iklan

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.
  • Proposal ini dimaksudkan untuk memberikan kemampuan kepada pengguna untuk mereset FLEDGE sepenuhnya. Jika hal ini terjadi, semua audiens kustom yang ada di perangkat akan dihapus.
  • Proposal ini juga memberikan pilihan kepada pengguna untuk memilih tidak ikut sepenuhnya dari Privacy Sandbox di Android, yang mencakup FLEDGE. Jika demikian, FLEDGE API akan gagal tanpa ada peringatan.

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

Mengambil iklan kandidat untuk audiens kustom

Platform sisi beli mungkin memiliki iklan kandidat berbasis interaksi pengguna yang disimpan di perangkat, sehingga platform tersebut dapat dievaluasi saat lelang untuk audiens kustom dijalankan. Iklan kandidat dan metadata terkait untuk audiens kustom dapat diambil dengan dua cara yang saling melengkapi.

  1. Pengambilan harian sistem: Ketika aplikasi bergabung dengan audiens kustom, aplikasi dapat menentukan URL update harian yang akan dibuat kueri oleh platform setiap hari. Platform teknologi iklan dapat menggunakan fitur ini untuk menjaga daftar iklan tetap baru dan menghapus iklan apa pun yang tidak lagi aktif atau tidak memiliki sisa anggaran.
  2. Pengambilan berdasarkan pemilik audiens kustom: Ketika menambahkan pengguna ke audiens kustom, pemilik dapat mengambil iklan kandidat dari platform sisi beli. Iklan dan metadata yang ditampilkan dapat disimpan di kolom "iklan" audiens kustom. Platform teknologi iklan mungkin ingin menggunakan fitur ini jika ingin segera mulai menayangkan iklan kepada pengguna.

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, data 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.