Dukungan lelang multi-penjual dengan Mediasi FLEDGE

Berikan masukan

Platform iklan sisi jual biasanya mendiversifikasi sumber permintaan iklan untuk mengoptimalkan pendapatan iklan. Dengan mediasi iklan, jaringan atau layanan iklan memanggil beberapa jaringan iklan untuk menentukan iklan terbaik pada slot iklan tertentu. Proposal ini memperkenalkan cara FLEDGE di Android dapat diperluas untuk menerapkan fungsi mediasi waterfall dengan cara yang menjaga privasi. Saat ini, jaringan iklan menyediakan berbagai cara bagi developer aplikasi untuk memediasi lelang iklan dari beberapa penjual iklan:

1. Mediasi waterfall: Developer aplikasi menentukan daftar jaringan iklan yang diurutkan, sering kali diberi peringkat berdasarkan eCPM historis untuk jaringan tertentu. Daftar ini dikenal sebagai rantai mediasi. Platform mediasi developer aplikasi menggunakan daftar ini untuk memanggil jaringan iklan sesuai urutan yang tercantum untuk menentukan sumber permintaan iklan yang relevan.
2. Mediasi terprogram: Beberapa jaringan iklan dikonfigurasi oleh developer aplikasi untuk berpartisipasi dalam bidding peluang iklan. Jaringan ini diizinkan untuk mengajukan bid secara real time berdasarkan cara jaringan tersebut menilai peluang.
3. Mediasi campuran: Kombinasi teknik mediasi waterfall dan terprogram.

Mediasi waterfall

Dalam mediasi waterfall, saat peluang iklan muncul, SDK iklan akan mengirimkan permintaan ke server backend-nya. Bukan merespons permintaan dengan materi iklan pemenang, server akan merespons dengan rantai mediasi yang berisi daftar jaringan iklan yang diurutkan berdasarkan eCPM historis.

Gambar 1. Model mediasi waterfall

Dalam model waterfall tradisional, SDK iklan memanggil setiap jaringan iklan (atau SDK lelangnya sendiri) dalam urutan yang ditetapkan oleh rantai mediasi. Jika jaringan iklan dapat memenuhi permintaan iklan, jaringan iklan akan merender iklan. Jika tidak, permintaan tersebut akan dikirim ke jaringan berikutnya dalam rantai tersebut. Proses ini diulang sampai permintaan terpenuhi atau rantai habis.

Mediasi waterfall sering kali dioptimalkan dengan mengurutkan ulang rantai mediasi secara rutin berdasarkan evaluasi ulang eCPM dari sumber permintaan iklan pihak pertama.

Mediasi terprogram

Mediasi terprogram (juga dikenal sebagai "bidding header") adalah cara alternatif untuk menggunakan eCPM historis guna menentukan jaringan iklan yang berkesempatan menayangkan permintaan iklan. Dengan mediasi terprogram, penyedia menggunakan nilai bid live untuk menemukan iklan pemenang.

Gambar 2: Model mediasi terprogram

Mediasi campuran

Beberapa solusi mediasi terprogram menggabungkan jaringan iklan mode campuran waterfall dan bidding untuk memberikan kontrol lebih besar terhadap iklan sekaligus mendapatkan manfaat penggunaan eCPM live untuk memaksimalkan pendapatan dari jaringan iklan yang berpartisipasi.

Dalam model mediasi campuran, jaringan iklan dan penyedia mediasi dapat meningkatkan fleksibilitas bagi developer aplikasi dengan menggabungkan elemen waterfall dan bidding real-time. Model campuran memungkinkan developer aplikasi mengonfigurasi jaringan iklan berdasarkan eCPM historis, sehingga memberi mereka peluang untuk menampilkan iklan sebelum menjalankan bidding real-time dengan jaringan yang berpartisipasi untuk mengisi peluang iklan.

Mediasi waterfall FLEDGE

FLEDGE untuk Android mendukung mediasi waterfall dengan memiliki beberapa lelang FLEDGE, masing-masing untuk satu node dalam grafik mediasi. Jika tidak ada pemenang lelang, node lelang jaringan berikutnya dipanggil hingga rantai habis. Proses mediasi waterfall adalah sebagai berikut:

1. SDK mediasi mengambil rantai mediasi dari endpoint server iklan kontekstual, yang dapat menampilkan iklan kontekstual atau rantai mediasi.
2. Jika endpoint server iklan menampilkan rantai mediasi, SDK mediasi akan melakukan iterasi melalui setiap item rantai secara berurutan, dengan memanggil SDK jaringan iklan yang berpartisipasi untuk menjalankan pemilihan iklan kontekstual dan pemasaran ulang. Setiap item dalam rantai mewakili permintaan jaringan iklan untuk membeli ruang iklan dengan harga tertentu untuk jumlah tayangan, klik, atau waktu iklan tertentu.
3. Jika tidak ada item baris dalam rantai yang memilih iklan pemenang, SDK mediasi dapat memilih untuk menampilkan iklan dari jaringan iklannya sendiri dengan menjalankan pemilihan iklan FLEDGE yang mempertimbangkan iklan pemasaran ulang dan kontekstual.

Gambar 3. Mediasi waterfall dengan FLEDGE.

Diagram di atas menunjukkan contoh algoritma mediasi waterfall yang dapat diterapkan oleh SDK mediasi, tetapi tidak dapat dioptimalkan oleh jaringan iklan pihak pertama. FLEDGE mendukung pengoptimalan jaringan iklan pihak pertama dengan memungkinkan rantai alur kerja pemilihan iklan dan melaporkan tayangan pemenang.

Hasil AdSelection

Jenis nilai yang ditampilkan selectAds() adalah objek AdSelectionOutcome. AdSelectionOutcome berisi URI render iklan pemenang dan AdSelectionId, yang merupakan bilangan bulat buram yang mengidentifikasi materi iklan item baris pemenang.

AdSelectionOutcome {
  Uri renderUri;
  Long AdSelectionId;
}

AdSelectionId bertindak seperti pointer ke AdSelectionOutcome. Saat ini, AdSelectionId diteruskan ke metode reportResult() sebagai parameter ReportImpressionInput untuk membantu mengidentifikasi iklan yang benar yang dipanggil pada metode reportWin() dan reportResult().

Membuat rantai proposal pemilihan iklan

Kami mengusulkan untuk memperluas selectAds() guna mempertimbangkan hasil dari pemilihan iklan sebelumnya yang dijalankan untuk memilih iklan pemenang melalui objek AdSelectionOutcome. Tindakan ini memungkinkan jaringan iklan menjalankan mediasi yang mempertimbangkan iklan kontekstual dan pemasaran ulang dari beberapa jaringan iklan.

ChainedAdSelections ditambahkan sebagai parameter opsional ke AdSelectionConfig. ChainedAdSelections dapat berisi daftar hasil pemilihan iklan dari pemanggilan metode selectAds() sebelumnya dalam rantai mediasi. Dalam contoh berikut, SDK menjalankan AdSelection menggunakan hasil dari SDK A dan SDK B di perangkat. SDK A dan B secara eksplisit berbagi AdSelectionOutcome dari panggilan selectAds() masing-masing ke SDK yang menjalankan pemilihan iklan berantai.

AdSelectionConfig myAdSelectionConfig = new AdSelectionConfig {
    Seller = "example-ssp1.com",
    DecisionLogicURL = Uri.parse("https://..."),
    CustomAudienceBuyerList = Arrays.asList("example-dsp1.com","example-dsp2.com"),
    AdSelectionSignals = "{"min_price": 10,"auction_attempts": 3}"
    SellerSignals = "{"seller_type": "news", "content_category": "sports","mature_ads_accepted" :"false"}"
    PerBuyerSignals = "{"example-dsp1.com": {"key1" : "value1"},
                        "example-dsp2.com": {"key1" : "value1", "key2" : "value2"}"
    ChainedAdSelections = {network_a_selection_outcome, network_b_selection_outcome}
};

// Invoke ad services API to initiate ad selection workflow.
AdSelectionOutcome winningAd = selectAds(myAdSelectionConfig);

Gambar 4. Membuat rantai pemilihan iklan dengan selectAds().

Perhatikan bahwa nilai yang ditampilkan panggilan selectAds() ini adalah objek AdSelectionOutcome lainnya.

• Nilai null akan ditampilkan jika tidak ada iklan yang dipilih.
• Objek AdSelectionOutcome baru akan ditampilkan jika salah satu iklan yang dirujuk oleh ChainedAdSelections bukan iklan pemenang.
• Salah satu hasil yang diteruskan di AdSelection akan ditampilkan jika iklan tersebut adalah iklan yang dipilih.

Melaporkan tayangan pemenang

Jika tidak ada pemenang pada pemilihan iklan berantai, tidak ada tayangan pemenang yang diharapkan akan dilaporkan.

Jika salah satu objek AdSelectionOutcome yang diteruskan ke AdSelectionConfig dipilih, SDK yang menjalankan pemilihan iklan berantai diharapkan dapat berkomunikasi dengan SDK iklan pemenang tentang hasilnya. SDK iklan pemenang kemudian dapat memanggil laporan tayangan pemenang seperti yang akan dilakukan setelah menjalankan AdSelection-nya sendiri. Hal ini akan memastikan bahwa JavaScript logika keputusan SDK iklan pemenang digunakan untuk melaporkan hasil. Dalam skenario ini, SDK yang menjalankan pemilihan iklan berantai dapat melaporkan SDK iklan mana yang memiliki tayangan pemenang.

Jika tidak ada hasil AdSelectionOutcome yang dipilih, SDK yang menjalankan pemilihan iklan berantai akan memanggil laporan tayangan pemenangnya.

Menjalankan mediasi waterfall

Dengan kemampuan untuk membuat rantai instance AdSelectionOutcome, seperti yang dijelaskan di awal halaman ini, SDK mediasi dapat menjalankan mediasi waterfall sekaligus memungkinkan jaringan iklan pihak pertama dioptimalkan. Proses ini diringkas sebagai berikut:

1. SDK mediasi memperoleh rantai mediasi dari server mediasi menggunakan permintaan iklan kontekstual.
2. SDK mediasi menjalankan pemilihan iklan yang mempertimbangkan iklan kontekstual dan pemasaran ulang.

3. SDK mediasi menjalankan lelang yang mempertimbangkan hasil pemilihan iklan pihak pertama dan eCPM historis dari item pertama yang memenuhi syarat dalam rantai mediasi.

4. Jika iklan dipilih, iklan pemenang akan ditentukan dan prosesnya berakhir.

5. Jika tidak ada iklan yang dipilih, SDK mediasi akan memilih item pertama yang memenuhi syarat dari rantai mediasi dan memanggil SDK yang sesuai untuk menjalankan pemilihan iklan pemasaran ulang dan kontekstual.

6. Jika iklan dipilih, iklan akan dirender dan proses berakhir.

7. Jika iklan tidak dipilih, item berikutnya dalam rantai tersebut akan dipertimbangkan, dan langkah 3 akan dijalankan.

8. Jika tidak ada lagi item dalam rantai, SDK mediasi akan menampilkan iklan pihak pertama dengan menjalankan pemilihan iklan FLEDGE yang mempertimbangkan iklan pemasaran ulang dan kontekstual, mirip dengan langkah 2.

Gambar 5. Proses mediasi waterfall FLEDGE.

Praktik terbaik

Menjalankan lelang kontekstual sebelum pengoptimalan pihak pertama

Permintaan pemasaran ulang dapat menghasilkan bid tinggi yang dapat memberikan hasil pemenang dalam rantai mediasi. Pemotongan adalah proses yang sering digunakan untuk mengaktifkan pengoptimalan pihak pertama dengan menyaring daftar audiens pemasaran ulang.

Permintaan pemasaran ulang FLEDGE hanya tersedia pada sisi klien dengan lelang FLEDGE. Hal ini dapat mempersulit pengaktifan pengoptimalan pihak pertama di sisi server. Untuk mengurangi masalah dengan pengoptimalan pihak pertama, jalankan lelang kontekstual terlebih dahulu, lalu lakukan pengoptimalan pihak pertama berdasarkan hasil iklan pemenang seperti yang dijelaskan sebelumnya di halaman ini.

Memastikan rantai mediasi di perangkat tetap kecil

Untuk mendapatkan performa optimal, rantai mediasi di perangkat harus berukuran kecil. Biaya komputasi untuk eksekusi di perangkat mungkin bersifat linier pada jumlah lelang yang dievaluasi sebagai bagian dari rantai mediasi. Dengan kata lain, lebih banyak node akan menghasilkan lebih banyak persyaratan siklus komputasi dan meningkatkan latensi. Pertimbangkan dampak latensi terhadap pendapatan saat Anda meneruskan node ke evaluasi mediasi di perangkat.

Pertimbangan tambahan

Proposal untuk mediasi FLEDGE ini masih dalam proses pengembangan, dan masukan sangat diharapkan.

FLEDGE saat ini tidak menawarkan solusi komprehensif untuk mediasi beberapa slot iklan. Setiap slot iklan harus diproses secara terpisah.

FLEDGE Mediation API saat ini mendukung mediasi waterfall dan mediasi terprogram terbatas. Detail selengkapnya tentang cara mendukung kasus penggunaan mediasi terprogram tambahan akan dibagikan di masa mendatang.

Karena pemilihan iklan FLEDGE berjalan setelah iklan kontekstual diambil, pemanggilan FLEDGE dapat memengaruhi latensi permintaan iklan secara menyeluruh.