Tampaknya bidang periklanan online harus secanggih dan seotomatis mungkin. Tentu saja, karena raksasa dan pakar di bidangnya seperti Yandex, Mail.Ru, Google, dan Facebook bekerja di sana. Namun, ternyata, kesempurnaan tidak ada batasnya dan selalu ada sesuatu yang dapat diotomatisasi.
Kelompok komunikasi Jaringan Dentsu Aegis Rusia adalah pemain terbesar di pasar periklanan digital dan secara aktif berinvestasi dalam teknologi, mencoba mengoptimalkan dan mengotomatiskan proses bisnisnya. Salah satu masalah yang belum terpecahkan di pasar periklanan online adalah tugas mengumpulkan statistik kampanye periklanan dari berbagai platform Internet. Pemecahan masalah ini pada akhirnya menghasilkan terciptanya suatu produk D1.Digital (dibaca DiVan), yang perkembangannya ingin kita bicarakan.
Kenapa?
1. Pada saat dimulainya proyek, tidak ada satu pun produk siap pakai di pasar yang memecahkan masalah otomatisasi pengumpulan statistik kampanye periklanan. Ini berarti bahwa tidak seorang pun kecuali diri kita sendiri yang dapat memenuhi kebutuhan kita.
Layanan seperti Improvado, Roistat, Supermetrics, SegmentStream menawarkan integrasi dengan platform, jejaring sosial, dan Google Analitycs, dan juga memungkinkan pembuatan dasbor analitis untuk memudahkan analisis dan kontrol kampanye periklanan. Sebelum kami mulai mengembangkan produk kami, kami mencoba menggunakan beberapa sistem ini untuk mengumpulkan data dari situs, namun sayangnya, sistem tersebut tidak dapat menyelesaikan masalah kami.
Masalah utamanya adalah produk yang diuji didasarkan pada sumber data, menampilkan statistik penempatan berdasarkan situs, dan tidak menyediakan kemampuan untuk mengumpulkan statistik kampanye iklan. Pendekatan ini tidak memungkinkan kami melihat statistik dari berbagai situs di satu tempat dan menganalisis keadaan kampanye secara keseluruhan.
Faktor lainnya adalah pada tahap awal produk ditujukan untuk pasar Barat dan tidak mendukung integrasi dengan situs Rusia. Dan untuk situs-situs yang integrasinya telah diterapkan, semua metrik yang diperlukan tidak selalu diunduh dengan cukup detail, dan integrasi tersebut tidak selalu mudah dan transparan, terutama ketika diperlukan untuk mendapatkan sesuatu yang tidak ada dalam antarmuka sistem.
Secara umum, kami memutuskan untuk tidak beradaptasi dengan produk pihak ketiga, tetapi mulai mengembangkan produk kami sendiri...
2. Pasar periklanan online berkembang dari tahun ke tahun, dan pada tahun 2018, dalam hal anggaran periklanan, pasar ini melampaui pasar periklanan TV yang biasanya terbesar. Jadi ada skalanya.
3. Berbeda dengan pasar periklanan TV, di mana penjualan iklan komersial dimonopoli, terdapat banyak pemilik individu inventaris periklanan dengan berbagai ukuran yang beroperasi di Internet dengan akun periklanan mereka sendiri. Karena kampanye periklanan, biasanya, berjalan di beberapa situs sekaligus, untuk memahami keadaan kampanye periklanan, perlu mengumpulkan laporan dari semua situs dan menggabungkannya menjadi satu laporan besar yang akan menampilkan gambaran keseluruhan. Artinya ada potensi optimasi.
4. Bagi kami, pemilik inventaris periklanan di Internet sudah memiliki infrastruktur untuk mengumpulkan statistik dan menampilkannya di akun periklanan, dan mereka akan dapat menyediakan API untuk data ini. Artinya secara teknis dimungkinkan untuk dilaksanakan. Katakanlah segera bahwa ternyata tidak sesederhana itu.
Secara umum, semua prasyarat untuk implementasi proyek sudah jelas bagi kami, dan kami berlari untuk mewujudkan proyek ini...
Rencana besar
Untuk memulainya, kami membentuk visi sistem yang ideal:
- Kampanye periklanan dari sistem korporat 1C harus secara otomatis dimuat ke dalamnya dengan nama, periode, anggaran, dan penempatannya di berbagai platform.
- Untuk setiap penempatan dalam kampanye periklanan, semua kemungkinan statistik harus diunduh secara otomatis dari situs tempat penempatan dilakukan, seperti jumlah tayangan, klik, penayangan, dll.
- Beberapa kampanye periklanan dilacak menggunakan pemantauan pihak ketiga oleh apa yang disebut sistem periklanan seperti Adriver, Weborama, DCM, dll. Ada juga pengukur Internet industri di Rusia - perusahaan Mediascope. Menurut rencana kami, data dari pemantauan independen dan industri juga harus secara otomatis dimuat ke dalam kampanye iklan terkait.
- Sebagian besar kampanye periklanan di Internet ditujukan pada tindakan target tertentu (pembelian, panggilan, mendaftar untuk uji coba, dll.), yang dilacak menggunakan Google Analytics, dan statistiknya juga penting untuk memahami status kampanye dan harus dimuat ke alat kami.
Panekuk pertama kental
Mengingat komitmen kami terhadap prinsip-prinsip pengembangan perangkat lunak yang fleksibel (agile, semua hal), kami memutuskan untuk mengembangkan MVP terlebih dahulu dan kemudian bergerak menuju tujuan yang diinginkan secara berulang.
Kami memutuskan untuk membangun MVP berdasarkan produk kami DANBo (Dewan Jaringan Dentsu Aegis), yang merupakan aplikasi web dengan informasi umum tentang kampanye iklan klien kami.
Untuk MVP, proyek ini disederhanakan semaksimal mungkin dalam hal implementasi. Kami telah memilih daftar terbatas platform untuk integrasi. Ini adalah platform utama seperti Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB, dan sistem periklanan utama Adriver dan Weborama.
Untuk mengakses statistik situs melalui API, kami menggunakan satu akun. Manajer grup klien yang ingin menggunakan pengumpulan statistik otomatis pada kampanye periklanan harus terlebih dahulu mendelegasikan akses ke kampanye iklan yang diperlukan di situs ke akun platform.
Berikutnya adalah pengguna sistem DANBo harus mengunggah file dengan format tertentu ke dalam sistem Excel, yang berisi semua informasi tentang penempatan (kampanye iklan, platform, format, periode penempatan, indikator yang direncanakan, anggaran, dll.) dan pengidentifikasi kampanye iklan terkait di situs dan penghitung dalam sistem periklanan.
Sejujurnya, itu tampak menakutkan:
Data yang diunduh disimpan ke dalam basis data, dan kemudian layanan terpisah mengumpulkan pengidentifikasi kampanye di situs-situs tersebut dan mengunduh statistiknya.
Untuk setiap situs, layanan Windows terpisah ditulis, yang sekali sehari berada di bawah satu akun layanan di API situs dan mengunduh statistik untuk ID kampanye tertentu. Hal yang sama terjadi pada sistem adserving.
Data yang diunduh ditampilkan pada antarmuka dalam bentuk dasbor khusus kecil:
Tanpa diduga bagi kami, MVP mulai bekerja dan mulai mengunduh statistik terkini tentang kampanye periklanan di Internet. Kami menerapkan sistem ini pada beberapa klien, namun saat mencoba melakukan penskalaan, kami menemui masalah serius:
- Masalah utamanya adalah rumitnya penyiapan data untuk dimuat ke dalam sistem. Selain itu, data penempatan harus dikonversi ke format yang tetap sebelum dimuat. Penting untuk menyertakan pengidentifikasi entitas dari berbagai situs dalam file unduhan. Kami dihadapkan pada kenyataan bahwa sangat sulit bagi pengguna yang tidak terlatih secara teknis untuk menjelaskan di mana menemukan pengidentifikasi ini di situs dan di mana mereka harus dimasukkan dalam file. Mengingat jumlah karyawan di departemen yang menjalankan kampanye di situs dan omzetnya, hal ini mengakibatkan banyaknya dukungan dari pihak kami, yang mana kami sama sekali tidak puas.
- Masalah lainnya adalah tidak semua platform periklanan memiliki mekanisme untuk mendelegasikan akses kampanye periklanan ke akun lain. Namun meskipun mekanisme delegasi tersedia, tidak semua pengiklan bersedia memberikan akses ke kampanye mereka kepada akun pihak ketiga.
- Faktor penting adalah kemarahan yang timbul di kalangan pengguna karena semua indikator yang direncanakan dan detail penempatan yang telah mereka masukkan ke dalam sistem akuntansi 1C kami, mereka harus memasukkannya kembali ke dalam DANBo.
Hal ini memberi kami gambaran bahwa sumber utama informasi penempatan haruslah sistem 1C kami, di mana semua data dimasukkan secara akurat dan tepat waktu (maksudnya faktur dibuat berdasarkan data 1C, jadi entri data yang benar ke 1C merupakan prioritas bagi semua KPI). Ini adalah bagaimana konsep baru dari sistem muncul...
Konsep
Hal pertama yang kami putuskan untuk dilakukan adalah memisahkan sistem pengumpulan statistik kampanye iklan di Internet menjadi produk terpisah - D1.Digital.
Dalam konsep baru, kami memutuskan untuk memuatnya D1.Digital informasi tentang kampanye periklanan dan penempatan di dalamnya dari 1C, dan kemudian mengambil statistik dari situs dan sistem AdServing ke penempatan ini. Hal ini seharusnya menyederhanakan kehidupan pengguna secara signifikan (dan, seperti biasa, menambah lebih banyak pekerjaan bagi pengembang) dan mengurangi jumlah dukungan.
Masalah pertama yang kami temui bersifat organisasi dan terkait dengan fakta bahwa kami tidak dapat menemukan kunci atau tanda yang dapat digunakan untuk membandingkan entitas dari sistem yang berbeda dengan kampanye dan penempatan dari 1C. Faktanya adalah bahwa proses di perusahaan kami dirancang sedemikian rupa sehingga kampanye periklanan dimasukkan ke dalam sistem yang berbeda oleh orang yang berbeda (perencana media, pembelian, dll.).
Untuk mengatasi masalah ini, kami harus menciptakan kunci hash unik, DANBoID, yang akan menghubungkan entitas-entitas dalam sistem yang berbeda, dan dapat diidentifikasi dengan cukup mudah dan unik dalam kumpulan data yang diunduh. Pengidentifikasi ini dihasilkan dalam sistem internal 1C untuk setiap penempatan individu dan ditransfer ke kampanye, penempatan, dan penghitung di semua situs dan di semua sistem AdServing. Penerapan praktik penempatan DANBoID di semua penempatan memerlukan waktu, namun kami berhasil melakukannya :)
Kemudian kami menemukan bahwa tidak semua situs memiliki API untuk mengumpulkan statistik secara otomatis, dan bahkan situs yang memiliki API, tidak mengembalikan semua data yang diperlukan.
Pada tahap ini, kami memutuskan untuk secara signifikan mengurangi daftar platform untuk integrasi dan fokus pada platform utama yang terlibat dalam sebagian besar kampanye periklanan. Daftar ini mencakup semua pemain terbesar di pasar periklanan (Google, Yandex, Mail.ru), jejaring sosial (VK, Facebook, Twitter), sistem AdServing dan analitik utama (DCM, Adriver, Weborama, Google Analytics) dan platform lainnya.
Mayoritas situs yang kami pilih memiliki API yang menyediakan metrik yang kami butuhkan. Jika tidak ada API atau tidak berisi data yang diperlukan, kami menggunakan laporan yang dikirim setiap hari ke email kantor kami untuk memuat data (di beberapa sistem dimungkinkan untuk mengonfigurasi laporan tersebut, di sistem lain kami menyetujui pengembangan laporan tersebut untuk kita).
Saat menganalisis data dari situs yang berbeda, kami menemukan bahwa hierarki entitas di sistem yang berbeda tidak sama. Selain itu, informasi perlu diunduh dengan detail berbeda dari sistem berbeda.
Untuk mengatasi masalah ini, konsep SubDANBoID dikembangkan. Ide SubDANBoID cukup sederhana, kami menandai entitas utama kampanye di situs dengan DANBoID yang dihasilkan, dan kami mengunggah semua entitas bersarang dengan pengidentifikasi situs unik dan membentuk SubDANBoID sesuai dengan prinsip DANBoID + pengidentifikasi tingkat pertama entitas bersarang + pengidentifikasi entitas bersarang tingkat kedua +... Pendekatan ini memungkinkan kami menghubungkan kampanye iklan di sistem yang berbeda dan mengunduh statistik terperinci tentang kampanye tersebut.
Kami juga harus memecahkan masalah akses terhadap kampanye di berbagai platform. Seperti yang kami tulis di atas, mekanisme mendelegasikan akses kampanye ke akun teknis terpisah tidak selalu berlaku. Oleh karena itu, kami harus mengembangkan infrastruktur untuk otorisasi otomatis melalui OAuth menggunakan token dan mekanisme untuk memperbarui token tersebut.
Nanti di artikel ini kami akan mencoba menjelaskan lebih detail arsitektur solusi dan detail teknis implementasinya.
Arsitektur solusi 1.0
Saat memulai implementasi produk baru, kami memahami bahwa kami perlu segera menyediakan kemungkinan untuk menghubungkan situs baru, jadi kami memutuskan untuk mengikuti jalur arsitektur layanan mikro.
Saat merancang arsitektur, kami memisahkan konektor ke semua sistem eksternal - 1C, platform periklanan, dan sistem periklanan - ke dalam layanan terpisah.
Ide utamanya adalah semua konektor ke situs memiliki API yang sama dan merupakan adaptor yang membawa API situs ke antarmuka yang nyaman bagi kami.
Inti dari produk kami adalah aplikasi web, yang merupakan monolit yang dirancang sedemikian rupa sehingga dapat dengan mudah dibongkar menjadi layanan. Aplikasi ini bertanggung jawab untuk memproses data yang diunduh, menyusun statistik dari berbagai sistem dan menyajikannya kepada pengguna sistem.
Untuk berkomunikasi antara konektor dan aplikasi web, kami harus membuat layanan tambahan, yang kami sebut Connector Proxy. Ia melakukan fungsi Service Discovery dan Task Scheduler. Layanan ini menjalankan tugas pengumpulan data untuk setiap konektor setiap malam. Menulis lapisan layanan lebih mudah daripada menghubungkan perantara pesan, dan bagi kami penting untuk mendapatkan hasilnya secepat mungkin.
Untuk kesederhanaan dan kecepatan pengembangan, kami juga memutuskan bahwa semua layanan akan menjadi API Web. Hal ini memungkinkan untuk dengan cepat menyusun bukti konsep dan memverifikasi bahwa keseluruhan desain berfungsi.
Tugas terpisah yang agak rumit adalah menyiapkan akses untuk mengumpulkan data dari berbagai akun, yang, seperti yang kami putuskan, harus dilakukan oleh pengguna melalui antarmuka web. Ini terdiri dari dua langkah terpisah: pertama, pengguna menambahkan token untuk mengakses akun melalui OAuth, lalu mengonfigurasi pengumpulan data untuk klien dari akun tertentu. Memperoleh token melalui OAuth diperlukan karena, seperti yang telah kami tulis, tidak selalu mungkin untuk mendelegasikan akses ke akun yang diinginkan di situs.
Untuk membuat mekanisme universal untuk memilih akun dari situs, kami harus menambahkan metode ke API konektor yang mengembalikan Skema JSON, yang dirender ke dalam formulir menggunakan komponen JSONEditor yang dimodifikasi. Dengan cara ini, pengguna dapat memilih akun untuk mengunduh data.
Untuk mematuhi batasan permintaan yang ada di situs, kami menggabungkan permintaan pengaturan dalam satu token, namun kami dapat memproses token yang berbeda secara paralel.
Kami memilih MongoDB sebagai penyimpanan data yang dimuat untuk aplikasi web dan konektor, sehingga kami tidak perlu terlalu mengkhawatirkan struktur data pada tahap awal pengembangan, ketika model objek aplikasi berubah setiap dua hari sekali.
Kami segera mengetahui bahwa tidak semua data cocok di MongoDB dan, misalnya, lebih mudah untuk menyimpan statistik harian dalam database relasional. Oleh karena itu, untuk konektor yang struktur datanya lebih cocok untuk database relasional, kami mulai menggunakan PostgreSQL atau MS SQL Server sebagai penyimpanan.
Arsitektur dan teknologi yang dipilih memungkinkan kami membangun dan meluncurkan produk D1.Digital dengan relatif cepat. Selama dua tahun pengembangan produk, kami mengembangkan 23 konektor ke situs, memperoleh pengalaman berharga bekerja dengan API pihak ketiga, belajar menghindari jebakan situs berbeda, yang masing-masing memiliki situsnya sendiri, berkontribusi pada pengembangan API setidaknya 3 situs, secara otomatis mengunduh informasi tentang hampir 15 kampanye dan lebih dari 000 penempatan, mengumpulkan banyak masukan dari pengguna mengenai pengoperasian produk dan berhasil mengubah proses utama produk beberapa kali, berdasarkan masukan ini.
Arsitektur solusi 2.0
Dua tahun telah berlalu sejak dimulainya pembangunan D1.Digital. Peningkatan beban yang konstan pada sistem dan munculnya lebih banyak sumber data baru secara bertahap mengungkap masalah dalam arsitektur solusi yang ada.
Masalah pertama terkait dengan jumlah data yang diunduh dari situs. Kami dihadapkan pada kenyataan bahwa mengumpulkan dan memperbarui semua data yang diperlukan dari situs terbesar mulai memakan banyak waktu. Misalnya, pengumpulan data dari sistem periklanan AdRiver, yang dengannya kami melacak statistik sebagian besar penempatan, memerlukan waktu sekitar 12 jam.
Untuk mengatasi masalah ini, kami mulai menggunakan semua jenis laporan untuk mengunduh data dari situs, kami mencoba mengembangkan API mereka bersama dengan situs sehingga kecepatan operasinya memenuhi kebutuhan kami, dan memparalelkan pengunduhan data sebanyak mungkin.
Masalah lainnya berkaitan dengan pemrosesan data yang diunduh. Sekarang, ketika statistik penempatan baru tiba, proses multi-tahap penghitungan ulang metrik diluncurkan, yang mencakup memuat data mentah, menghitung metrik gabungan untuk setiap situs, membandingkan data dari sumber berbeda satu sama lain, dan menghitung metrik ringkasan untuk kampanye. Hal ini menyebabkan banyak beban pada aplikasi web yang melakukan semua perhitungan. Beberapa kali, selama proses penghitungan ulang, aplikasi menghabiskan seluruh memori di server, sekitar 10-15 GB, yang berdampak paling merugikan pada pekerjaan pengguna dengan sistem.
Masalah yang teridentifikasi dan rencana ambisius untuk pengembangan produk lebih lanjut membuat kami perlu mempertimbangkan kembali arsitektur aplikasi.
Kami mulai dengan konektor.
Kami memperhatikan bahwa semua konektor bekerja sesuai dengan model yang sama, jadi kami membangun kerangka pipa di mana untuk membuat konektor Anda hanya perlu memprogram logika langkah-langkahnya, sisanya bersifat universal. Jika beberapa konektor memerlukan perbaikan, maka kami segera mentransfernya ke kerangka baru bersamaan dengan perbaikan konektor tersebut.
Pada saat yang sama, kami mulai menerapkan konektor ke Docker dan Kubernetes.
Kami merencanakan perpindahan ke Kubernetes cukup lama, bereksperimen dengan pengaturan CI/CD, namun mulai berpindah hanya ketika satu konektor, karena kesalahan, mulai menghabiskan lebih dari 20 GB memori di server, sehingga hampir mematikan proses lainnya. . Selama penyelidikan, konektor dipindahkan ke kluster Kubernetes, dan konektor tersebut tetap ada, bahkan setelah kesalahan diperbaiki.
Kami segera menyadari bahwa Kubernetes nyaman digunakan, dan dalam waktu enam bulan kami mentransfer 7 konektor dan Proxy Konektor, yang menggunakan sumber daya paling banyak, ke kluster produksi.
Mengikuti konektornya, kami memutuskan untuk mengubah arsitektur aplikasi lainnya.
Masalah utamanya adalah data berasal dari konektor ke proxy dalam jumlah besar, lalu masuk ke DANBoID dan dikirim ke aplikasi web pusat untuk diproses. Karena banyaknya penghitungan ulang metrik, ada beban besar pada aplikasi.
Hal ini juga terbukti cukup sulit untuk memantau status pekerjaan pengumpulan data individual dan melaporkan kesalahan yang terjadi dalam konektor ke aplikasi web pusat sehingga pengguna dapat melihat apa yang terjadi dan mengapa data tidak dikumpulkan.
Untuk mengatasi masalah ini, kami mengembangkan arsitektur 2.0.
Perbedaan utama antara arsitektur versi baru ini adalah alih-alih API Web, kami menggunakan RabbitMQ dan perpustakaan MassTransit untuk bertukar pesan antar layanan. Untuk melakukan ini, kami harus menulis ulang hampir seluruhnya Connectors Proxy, menjadikannya Connectors Hub. Nama tersebut diubah karena peran utama layanan tidak lagi meneruskan permintaan ke konektor dan sebaliknya, namun dalam mengelola kumpulan metrik dari konektor.
Dari aplikasi web pusat, kami memisahkan informasi tentang penempatan dan statistik dari situs ke dalam layanan terpisah, yang memungkinkan untuk menghilangkan penghitungan ulang yang tidak perlu dan hanya menyimpan statistik yang sudah dihitung dan dikumpulkan di tingkat penempatan. Kami juga menulis ulang dan mengoptimalkan logika untuk menghitung statistik dasar berdasarkan data mentah.
Pada saat yang sama, kami memigrasikan semua layanan dan aplikasi ke Docker dan Kubernetes untuk menjadikan solusi ini lebih mudah untuk diskalakan dan lebih nyaman untuk dikelola.
Dimana kita sekarang
Produk arsitektur bukti konsep 2.0 D1.Digital siap dan bekerja di lingkungan pengujian dengan serangkaian konektor terbatas. Yang perlu dilakukan hanyalah menulis ulang 20 konektor lainnya ke platform baru, menguji apakah data dimuat dengan benar dan semua metrik dihitung dengan benar, dan meluncurkan seluruh desain ke dalam produksi.
Faktanya, proses ini akan terjadi secara bertahap dan kita harus meninggalkan kompatibilitas dengan API lama agar semuanya tetap berfungsi.
Rencana jangka pendek kami meliputi pengembangan konektor baru, integrasi dengan sistem baru, dan penambahan metrik tambahan pada kumpulan data yang diunduh dari situs yang terhubung dan sistem periklanan.
Kami juga berencana untuk mentransfer semua aplikasi, termasuk aplikasi web pusat, ke Docker dan Kubernetes. Dikombinasikan dengan arsitektur baru, hal ini akan menyederhanakan penerapan, pemantauan, dan pengendalian sumber daya yang dikonsumsi secara signifikan.
Ide lainnya adalah bereksperimen dengan pilihan database untuk menyimpan statistik, yang saat ini disimpan di MongoDB. Kami telah mentransfer beberapa konektor baru ke database SQL, namun perbedaannya hampir tidak terlihat, dan untuk statistik gabungan harian, yang dapat diminta untuk jangka waktu berapa pun, keuntungannya bisa sangat serius.
Secara umum, rencananya muluk-muluk, mari kita lanjutkan :)
Penulis artikel R&D Dentsu Aegis Network Rusia: Georgy Ostapenko (), Mikhail Kotsik ()
Sumber: www.habr.com