Ad Exchange sebagai bagian dari Penawaran Waktu Nyata (RTB) adalah salah satu solusi AdTech yang mengubah pasar periklanan online. Fungsi utamanya adalah untuk merapat sejumlah besar SSP dan DSP yang tidak memiliki integrasi langsung antara satu sama lain, serta menjual kembali berbagai lalu lintas iklan di antara mereka.
Berkat pesanan untuk pasar AS, kami langsung terjun ke spesifik membangun platform Ad Exchange. Dan dalam artikel ini kami menyajikan beberapa ide dan hasil.
Pernyataan masalah
Penawaran Waktu Nyata (RTB) menyediakan penjualan ruang iklan di situs secara real time untuk menampilkan iklan yang relevan kepada audiens target.
Singkatnya, diagram proses adalah sebagai berikut:
- pengguna akhir meminta halaman web atau aplikasi seluler tempat tempat spanduk dicadangkan (kode untuk platform penjualan inventaris iklan sudah ada di dalamnya - SSP, Platform Sisi Pasokan);
- Untuk memastikan harga jual maksimum inventaris, SSP melalui Ad Exchange mengatur tender antara berbagai DSP (Platform Sisi Permintaan), yang tujuannya adalah untuk membeli inventaris semurah mungkin;
- setelah pengumuman pemenang lelang, DSP yang menang mengirimkan kode spanduk SSP, yang ditampilkan kepada pengguna;
- sisi lain dari proses ini adalah DMP, sistem pihak ketiga yang memberikan informasi terperinci kepada DSP tentang pengguna akhir (di luar apa yang dapat ditransmisikan oleh SSP dalam bentuk cookie, dll.) untuk membenarkan kelayakan pembelian dan biaya yang diusulkan.
Ada beberapa pertukaran Ad Exchange hari ini. Selain itu, banyak SSP menerapkan penawaran mereka sendiri (sebenarnya menutup fungsionalitas Ad Exchange). Tetapi pelanggan kami yakin bahwa karena beberapa ide baru, ia dapat dengan cepat memasuki pasar dan menahan persaingan.
Pertukaran bekerja pada prinsip-prinsip yang berbeda: seseorang menawarkan margin yang lebih besar, seseorang lebih sedikit, seseorang menjual peralatan unik, yang lain fokus pada barang konsumen bersyarat. Pasar cukup muda dan aktif berkembang, oleh karena itu tidak ada model bisnis yang diuji selama bertahun-tahun di sini: semuanya dibangun di atas hipotesis dan eksperimen yang berani. Sebagian besar pemain bekerja sesuai dengan skema sederhana: mereka menerima permintaan dari salah satu dari beberapa SSP yang dapat mereka setujui, dan mengirimkannya ke semua DSP terintegrasi untuk mengantisipasi taruhan yang lebih baik. Pendapatan Ad Exchange - Perbedaan antara harga pembelian dan penjualan inventaris iklan pada SSP dan DSP dikurangi biaya operasi.
Klien kami menyarankan untuk mengoptimalkan skema ini dengan mendistribusikan permintaan SSP dengan benar ke DSP - tidak dengan sengaja mengirim permintaan "kehilangan", sehingga mengurangi biaya operasi. Karena ini, Anda dapat mengurangi komisi pertukaran tanpa kehilangan pendapatan, dan membuat penawaran Anda lebih menarik dengan latar belakang Ad Exchange yang bersaing dalam perjuangan untuk SSP dan DSP. Dan menghubungkan lebih banyak mitra akan memberikan pemasukan dan stabilitas di pasar.
Untuk menerapkan strategi ini di pasar AS, kami ditugaskan untuk membuat Ad Exchange dengan distribusi permintaan yang cerdas, yaitu memberikan persentase pembelian kembali yang baik. Secara teori, untuk distribusi seperti itu, Anda dapat menggunakan banyak informasi yang menyertai permintaan, bahkan data dari sistem pihak ketiga yang disebutkan di atas (DMP). Namun, analitik yang kompleks membutuhkan sumber daya, sehingga tugas sebenarnya adalah menemukan keseimbangan antara biaya distribusi cerdas dan keuntungan (dibandingkan dengan pemain pasar lainnya) dari implementasinya. Dalam pasar yang belum matang yang relatif baru, membangun solusi yang sangat kompleks, meremas kesepuluh optimasi, sama sekali tidak masuk akal.
Fitur penting dari proyek, selain beban tinggi yang diharapkan, adalah pemenuhan persyaratan non-fungsional untuk kecepatan lelang yang dilakukan oleh SSP. Kecukupan dalam segmen pasar ini adalah batas waktu untuk menunggu tanggapan dari SSP hingga 300 ms, yang harus dipenuhi bersamaan dengan panggilan ke sistem eksternal (DSP).
Proyek ini dimulai pada musim gugur 2016. Berkat pengalaman tim di bidang ini, setelah tiga bulan kami membuat prototipe pertama, dan setelah tiga MVP (Produk Minimum yang Layak) siap, yang memungkinkan kami mengumpulkan analitik pertama untuk memulai distribusi cerdas permintaan di Ad Exchange.
Peluncuran MVP menunjukkan bahwa hipotesis tentang keberhasilan komersial proyek sudah benar - Ad Exchange mulai menghasilkan uang untuk klien. Rencana pengembangan awal untuk Ad Exchange mencakup studi yang lebih mendalam tentang data - yang menghubungkan informasi pengguna akhir dari sistem eksternal ke analitik. Tetapi pada tahap MVP, diputuskan untuk hanya menggunakan data yang dimiliki SSP. Ini cukup untuk menghasilkan keuntungan yang diharapkan.
Arsitektur Solusi
Solusi ini dibangun di atas rantai Chain of responsibility, yang memungkinkan untuk tidak memperbaiki rute permintaan dalam sistem, dengan mudah menambahkan prosesor dan berbagai layanan, dari pelelangan itu sendiri hingga alat penyaringan.
Pelanggan tidak membatasi kami dalam tumpukan teknologi yang digunakan. Oleh karena itu, dengan memperhatikan perkembangan masa depan dan dukungan proyek, kami membangun solusi yang dapat diskalakan secara horizontal menggunakan Postgres dan Hadoop.
Ad Exchange sendiri ditulis dalam Java - pada saat yang sama, kami tidak menggunakan kerangka kerja apa pun agar tidak merosot di beban (kami bekerja di level rendah).
Untuk tetap berada dalam batas waktu SSP yang disebutkan, kami memilih parameter pengumpul sampah (G1 digunakan) dan mengerjakan pekerjaan sinkron dengan sejumlah besar permintaan - kami menggunakan klien HTTP yang tidak memblokir aliran, serta perpanjangan protokol HTTP keep-live yang memungkinkan pengiriman beberapa permintaan dalam satu koneksi TCP.
Komponen perangkat lunak digunakan pada perangkat keras yang disewa dari host, sebagai kondisi tugas tidak memungkinkan penggunaan cloud karena sumber daya mesin virtual cloud yang tumpang tindih (alokasi sumber daya yang diperlukan mungkin memerlukan waktu, tetapi kami tidak memilikinya). Saat ini, Ad Exchange menggunakan empat server fisik, salah satunya adalah redundan (untuk pembaruan yang lancar, dll.).
Sumber terbuka Apache Kafka digunakan sebagai perantara pesan - idealnya diintegrasikan ke dalam model "satu pelanggan - banyak penerbit" kami, meskipun harus sedikit diputar sehingga pesan yang diulang tidak sampai.
Setiap server menyediakan dalam mode normal yang memproses sekitar 10 ribu permintaan per detik (parameter ini ditetapkan selama pengembangan solusi). Sekarang beban rata-rata adalah 15-20 ribu permintaan per detik, dan pada puncaknya aliran permintaan mencapai 40 ribu per detik selama beberapa jam, dan Ad Exchange melakukan pekerjaan yang baik untuk ini.
Distribusi permintaan antar server dilakukan oleh load balancer perangkat lunak nginx, yang dikonfigurasi untuk tugas kami. Dalam pengalaman kami, pada nginx Anda dapat menyimpan hingga 60-70 ribu permintaan per detik, tanpa mengalokasikan penyeimbang perangkat keras terpisah. Jika di masa depan beban di Ad Exchange akan di atas ambang ini, kami berencana untuk membeli penyeimbang perangkat keras yang akan mendistribusikan permintaan antara beberapa jenis nginx yang sama.
Ia memantau apa yang terjadi, yang tunduk pada peningkatan beban yang konstan, sistem pemantauan, yang merupakan bagian dari Ad Exchange yang dibuat.
Penyimpanan
Mengingat ketergantungan pada analitik selama distribusi kueri, basis data merupakan bagian integral dari Ad Exchange kami. Sistem menyimpan informasi tentang tawaran, peserta lelang, dan transaksi.
Tidak masuk akal untuk mengumpulkan volume data seperti itu untuk seluruh periode Ad Exchange, sehingga penyimpanan memiliki arsitektur multi-level. Semua data lelang disimpan per minggu. Berdasarkan mereka, unit tingkat menengah yang lebih tinggi dibangun, yang disimpan selama beberapa bulan. Dan atas dasar yang menengah, agregat akhir digunakan, yang digunakan dalam analitik jangka panjang dan untuk rekonsiliasi dengan SSP dan DSP. Di antara informasi lain di unit-unit ini ada data tentang berapa banyak taruhan yang telah dibuat dan berapa banyak uang yang akan dibayarkan pertukaran oleh SSP atau yang diharapkan akan diterima dari DSP.
Titik akhir disimpan selama seluruh durasi Ad Exchange.
Pengumpulan analitik dan pembentukan agregat menyediakan layanan terpisah.
Agar penyimpanan sesuai dengan kecepatan sistem itu sendiri, saya juga harus bekerja dengannya. Khususnya, untuk beberapa waktu kami berkelahi dengan hoster, karena data transaksi sama sekali tidak punya waktu untuk menulis ke database. Ternyata kesalahannya adalah masalah perangkat keras dengan array RAID. Setelah menggantinya, kami dapat memeras 90.000 permintaan per detik pada Postgres (dengan memasukkan data ke dalam basis data).
Ad Exchange lainnya tidak memiliki kewarganegaraan, yang memberikan penskalaan horizontal yang mudah di masa mendatang. Itu tidak menyimpan data apa pun berdasarkan permintaan - informasi maksimum yang diterima tentang DSP mana yang harus dipilih. Sehingga kami dapat menambahkan server baru untuk memproses permintaan sesuai kebutuhan.
Pemfilteran lalu lintas
Elemen kunci dari sistem yang memungkinkan Anda untuk mengurangi beban dan mempertahankan batas waktu yang ditunjukkan oleh pelanggan adalah pemfilteran lalu lintas.
Menurut tugas yang dihadapi, Ad Exchange apa saja:
- menerima permintaan dari SSP;
- mengadakan lelang (mengirimkan permintaan ke beberapa DSP, membandingkan harga yang ditawarkan, mengidentifikasi pemenang);
- setuju dengan kemenangan SSP (melaporkan harga pemenang dikurangi komisinya, menunggu tanggapan dengan harga akhir pertunjukan);
- menyelesaikan transaksi (melaporkan ke DSP yang diperlukan tentang kemenangannya, melakukan lalu lintas pengguna).
Distribusi permintaan pintar di Ad Exchange kami termasuk pada tahap awal lelang.
Ketika kami menerima permintaan dari SSP dengan informasi tertentu (IP, agen pengguna), kami merincinya menggunakan informasi yang terakumulasi dalam informasi pengguna yang diketahui sistem, daftar DSP yang dikirimi permintaan serupa, responsnya, dll. Ini diperlukan untuk memilih kombinasi DSP yang paling menguntungkan untuk setiap permintaan. Berkat pemilihan kombinasi seperti itu, sistem ini memungkinkan Anda untuk tidak mengirim permintaan ke DSP yang tidak menawar atau melakukan, tetapi terlalu rendah. Untuk melakukan ini, layanan terpisah dalam waktu nyata mengumpulkan peta tentang bagaimana DSP menanggapi permintaan (kartu-kartu ini disimpan di Redis).
Secara paralel, kami memeriksa status DSP - jika proporsi respons dalam batas waktu turun, sistem secara otomatis mengurangi jumlah permintaan ke DSP ini. Segera setelah beban pada DSP berkurang (dan proporsi jawaban yang benar dalam waktu yang dapat diterima bertambah), jumlah permintaan secara bertahap kembali ke tingkat sebelumnya.
Di antara DSP yang menjawab tepat waktu, kami mengadakan lelang internal - pilih penawaran terbaik dan kirimkan ke SSP. Dari saat permintaan dari SSP hingga tanggapan kami, tidak lebih dari 300 ms berlalu, sesuai dengan persyaratan industri.
Karena kami mengirim data ke SSP, tempat lelang kami diadakan, kami perlu mempertimbangkan tawaran yang dimenangkan di sana. Server lelang terlibat dalam pendataannya pada tahap berikutnya, saat memproses lalu lintas pengguna. Berkat dia, peta respons DSP diperkaya dengan data baru (bersama dengan informasi yang dikumpulkan tentang pengguna akhir).
Perbandingan data yang diperoleh pada tahap lelang dan parameter yang diketahui dari lalu lintas pengguna memungkinkan kami untuk memfilter bot (klik iklan, bot pencarian, dll.). Lalu lintas semacam itu tidak ditebus oleh DSP, dan jika tidak ada sistem penyaringannya sendiri, itu berubah menjadi kerugian klien, yang harus ditutup dengan margin.
Perlu dicatat bahwa penyaringan lalu lintas bot tidak segera dimulai. Tapi setelah dimasukkannya kunci sederhana, kenaikan margin sekitar 50%.
Omong-omong, selain alat pemfilteran lalu lintas otomatis dalam sistem kami, adalah mungkin bagi pelanggan untuk secara manual mengubah nilai ambang batas sejumlah parameter, sehingga menyesuaikan margin.
Lalu lintas pengguna itu sendiri sangat penting bagi kami, tetapi ketika diproses, tidak perlu lagi masuk ke dalam 300 ms. Ini menggunakan sistem pemrosesan yang terpisah, yang bisa menahan pengguna sedikit, tetapi tidak akan membiarkan kehilangan permintaan ini.
Untuk memastikan stabilitas solusi, sebuah subsistem diperkenalkan, yang, memahami beban Ad Exchange saat ini, "memotong" permintaan untuk lelang, yang tidak dapat diproses secara fisik. Dengan demikian, sistem dilindungi dari pertumbuhan beban yang tidak terkendali dari SSP.
Prospek
Hingga saat ini, Ad Exchange yang kami buat berfungsi dan menghasilkan untung besar. Dan kami menyediakan dukungan dan integrasi mitra baru (DSP / SSP) sebagaimana diperlukan. Secara total, beberapa lusin sistem telah terintegrasi. Setiap integrasi seperti itu menyiratkan tidak hanya koneksi perangkat lunak, tetapi juga pengujian komprehensif layanan, karena di bawah beban yang berat masalah layanan yang terhubung dapat mempengaruhi mitra lain.
Secara umum, pasar bergerak menuju fakta bahwa SSP dan DSP akan terhubung secara langsung, yang akan membuat pertukaran tidak perlu. Tetapi integrasi bertumpu pada kemampuan SSP dan DSP. Terlepas dari keberadaan API yang dideskripsikan secara terbuka (protokol OpenRTB), ia belum diakui secara universal di pasar. Sebagai contoh, pemain utama seperti Appnexus memiliki dukungan terintegrasi untuk OpenRTB baru-baru ini.
Intinya, Ad Exchange adalah penyedia likuiditas. Jadi keputusan dalam waktu dekat tidak mungkin kehilangan relevansinya. Selain itu, model pertukaran hanya mendapatkan popularitas di seluruh pasar periklanan.
Penulis artikel: Nikolay Eremin
PS Kami menerbitkan artikel kami di beberapa situs Runet. Berlangganan ke halaman kami di
VK ,
FB atau
saluran Telegram untuk mencari tahu tentang semua publikasi kami dan berita Maxilect lainnya.